[flac-dev] Two questions
Dear All,
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?
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.
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.
Thanks,
Federico Miyara
--
El software de antivirus Avast ha analizado este correo electrónico en busca de
virus.
https://www.avast.com/antivirus
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two questions
On Aug 2, 2021, at 08:40, Federico Miyara 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
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two questions
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
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two questions
On Aug 2, 2021, at 19:19, Federico Miyara wrote: > Brian, > > Thanks for your reply. > >> 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 recommend writing your own utility based on the FLAC library, in C, with the features you want. I do not recall any feature in the flac command line utility that would allow this. Your workaround is a reasonable attempt, but it seems to have too many undefined side-effects. > 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? The --keep-foreign-metadata feature was added to the command-line application after the FLAC format was finalized. The metadata ends up in an APPLICATION block, which is usually skipped by the FLAC library decoder. These are intended for third-party applications, and thus it's typically impossible to document them. Normally, a third-party software developer would add their own proprietary block to the FLAC file, and all other applications would just skip over it (because all blocks have a universal name and length at the start). This foreign metadata feature is a special case, where the command-line flac utility uses 'RIFF', 'riff' or 'aiff' as "application" names, when actually it's the external file format and not the application that's being referred to. https://xiph.org/flac/format.html#def_APPLICATION and https://xiph.org/flac/id.html The only documentation of the APPLICATION block format is probably the source code for the flac command line utility. I did not design this, but I remember suggesting it a few times. Basically, the entire WAV or AIFF contents are in the block, verbatim, except for the chunk that would contain the audio. Since the FLAC data outside the APPLICATION block already contains the audio, that chunk is empty in the APPLICATION block. By the way, one of the challenges of making a completely lossless WAV or AIFF compressor is that there is no predefined order for the various chunks in those files. The audio data chunk can appear before or after various other optional chunks. The solution for FLAC was to have that empty chunk inside the APPLICATION block. For WAV, the audio chunk is named 'data' and for AIFF the audio chunk is named 'SSND'. All other chunks are copied verbatim, but these audio chunks only have a name and size with no further bytes. It's basically a marker. I'm pretty sure that's how it was implemented, but you can check the flac command line source to confirm. >> 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. There are two level to the FLAC source code. At the lowest level is the FLAC library, which deals only with the FLAC stream, either seekable or restricted to streaming only. The FLAC library does not understand WAV or AIFF or anything besides FLAC. The high level code is separate, and it's the flac command line. So, yes, the flac command line returns the same sample type as the original file. However, if you use the FLAC library directly, you'll note that samples are always 32-bit fixed-point integers. I've written my own object-oriented framework to convert FLAC to WAV, AIFF, CAF, and other formats. In this code base, I had to deal with the 32-bit integers. My apologies for confusing the FLAC library with the output files from the flac command line. If you're going to use the command line, I'd recommend getting or writing some utilities that can analyze a WAV (or AIFF) file directly. Seems like some of the GUI applications out there can do unexpected things (for a long time, certain GUI apps would show MP3 song metadata in the audio samples!) > However, I made a more careful test and with skip=0 until=1 and get 2 samples > inst
