[flac-dev] Two questions

[Federico Miyara]

Brian,

Thanks for your reply.

> Yes. There is a specific header with this information. Look for the 
> documentation of the FLAC format for reference, and then look through 
> the library for calls that might return this information.

OK, I'll see that later.

> You should not use the RIFF information. It is not part of the FLAC 
> specification. It is an optional enhancement to store information that 
> is only about the input WAV files. It will strictly be missing from 
> FLAC files that are recorded live, converted from AIFF, and will even 
> be missing when WAV is the source if the option is not added.

I'm aware of that. It happens that my flac files (there are many of 
them) have been converted from wav files and contain riff cues and 
associated text that have been annotated, many years ago, according to a 
research protocol. I need to retrieve that information automatically. 
The encoding has been done preserving foreign metadata and tests have 
shown the information is correctly kept. I have a script that can 
retrieve the info from the wav file, so I decode a dummy wav with very 
few samples and the whole metadata stuff, but it would be better to 
retrieve that information directly from the file.

I've read the FLAC format and cannot find any mention to where are the 
foreign metadata included in the stream. Is it possible that it isn't 
actually documented yet?

> Are you seeing 3 bytes for 1 sample? ... or are you seeing 3 samples? 
> Also, I recall that the FLAC library returns 32-bit numbers, so you 
> have to convert these to 16-bit or 24-bit samples.

I think it returns exactly the sample type the original file contained, 
otherwise I guess it wouldn't be a lossless compressor.

However, I made a more careful test and with skip=0 until=1 and get 2 
samples instead of 3.

I confirm this in two different ways:
1) From the RIFF DATA header the size of audio data is 4 bytes, and my 
wav was originally encoded at 16 bit per sample
2) I open it in Audacity and it shows 2 samples

What confused me is that when I open the same file in Cool Edit 2000 (an 
ancient commercial audio editor) it displays 4 samples, I don't quite 
understand why. The first 2 ones are the first two of the original file, 
the 3rd and 4th are 0. But this anomalous behavior corresponds to Cool 
Edit, not FLAC. (My first example was with skip=1 until=1, so it should 
have yielded 1 sample but Cool Edit showed two more samples, both 0, 
which made the 3 samples)

Let's go back to the result: I have 2 samples. Since I had skipped 0 or 
no sample, I have the first two samples, so I guess the first one is #0 
and the second one is #1. But there is still a conflict with the 
documentation, which says (I quote again):

--until={#|[+|-]mm:ss.ss} Stop at the given sample number for each input 
file. _The given sample number is not included in the decoded output._

 From my sample case it would appear that the given sample number is 
indeed included in the decoded output.

If I'm correct, this wouldn't be exactly a bug but an error in the 
documentation.

Regards,

Federico Miyara




-- 
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20210802/62d1b003/attachment.htm>