flac dev - Aug 2021 - Two questions

On Aug 2, 2021, at 08:40, Federico Miyara <fmiyara at fceia.unr.edu.ar>
wrote:
> 1) Is there a way to get the audio size (number of samples) and other
information, such as number of channels, from a flac file without fully decoding
it?
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.

I usually start from https://xiph.org/flac/documentation_format_overview.html
for the official specification of the file format.

Note that FLAC is mostly a streaming format, where metadata is not generally
used. But the file does have this information early on. See
https://xiph.org/flac/format.html#def_STREAMINFO where it says that the
STREAMINFO packet must be the first packet in the file.
> I've found that the WAV header is replicated after the
"riffRIFF" keyword, but I don't seem to be able to predict where
it is located or whether it is safe or not to asume that the first time such
keyword appears is the correct one, and if there is an upper bound for its
location; for instance, some text such as the name of a song or some comment
could contain that keyword, even if it is unlikely. The information preceding
the  "reference libFLAC 1.3.3" encoder version seems to be non-text
information.
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.

> 2) I decode using the option --skip=0 --until=1. I would expect to get a
wav file with only 1 sample, but I get 3 samples. Stictly no sample should be
decoded since 0 samples should be skipped and the help says:
> 
> --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.
> 
> so sample #1 should not be included, unless the first sample is sample #0,
in which case only 1 sample, and not 3 samples, should be included in the output
file.
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.

Brian

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>