[Flac] Flac woes

Free Lunch freelunch at gmail.com
Sun Jun 10 11:31:02 PDT 2007


On 6/10/07, Scott F <graue at oceanbase.org> wrote:
> "Free Lunch" <freelunch at gmail.com> wrote:
>
> > WARNING: skipping unknown sub-chunk 'PAD '
>
> Are you saying the audio is hidden inside a chunk
> called "PAD "? What kind of a wav file has audio
> hidden within a padding chunk?

Flac apparently considers anything past the header-specified end of
audio as extra padding to be skipped.  Here is the original bug with
one example of how to create a test file:

http://sourceforge.net/tracker/index.php?func=detail&aid=1293830&group_id=13478&atid=113478

> You know, FLAC encodes only audio, and uses the
> file only as a vehicle for getting that audio. So
> I think it's justified in throwing out a padding
> chunk. What behavior would you prefer?

Btw, flac exits with a 0 exit code even when it discards extra EOA data.

I'd like flac to be able to include data beyond the header described
EOA. I'd suggest that it should do that by default as the safest
behavior and ignoring anything past EOA should be an option.  Better
general robustness in cases where a byte is missing at the end of the
WAV, etc, etc, would be nice and inspire more confidence.

Flac probably should not attempt to fix the header when extacting.
Ideally, from my perspective, the extracted WAV should exactly match
the original. That doesn't seem to be the case right now. Not being
able to do a simple md5 of a WAV to verify correctness creates new
challenges.   Even if you chop the header and compare the files, the
end of the file seems to get padded. So the lengths do not match.

> WARNING: legacy WAVE file has format type 1 but bits-per-sample=24?
>
> Some of my programs' wav files get that warning,
> too. I just looked into that, and apparently
> Microsoft's latest spec urges the use of an
> alternate header format (WAVE_FORMAT_EXTENSIBLE)
> for bit depths other than 8 and 16.

Gotcha.  Thanks.


Regards,
  FL


More information about the Flac mailing list