Howdy,
Flac-1.1.4 is refusing to encode some WAV files (amd64, gentoo):
% flac Song\ Name-Track01.wav
Song Name-Track01.wav: WARNING: legacy WAVE file has format type 1 but
bits-per-sample=24
Song Name-Track01.wav: 100% complete, ratio=0.546Song
Name-Track01.wav: ERROR during read of data pad byte
% sfinfo Song\ Name-Track01.wav
File Name Song Name-Track01.wav
File Format Microsoft RIFF WAVE Format (wave)
Data Format 24-bit integer (2's complement, little endian)
Audio Data 779761383 bytes begins at offset 44 (2c hex)
1 channel, 259920461 frames
Sampling Rate 48000.00 Hz
Duration 5415.010 seconds
I did a search on the error message and found someone else with a
similar problem and Josh's reply said:
> but the wave file seems invalid. sample data is supposed to be
> padded to an even number of bytes.
The gotcha here, as I have tried to explain in similar cases before,
is that we do not live in a perfect world. Many of us record audio
and are unable to control whether a piece of hardware crashes and
leaves the end of a WAV perfectly aligned or padded. In this case the
recorder (Alesis hd24) did not crash, it apparently just doesn't pad.
Since these are original audio masters being backed up, editing them
isn't a viable option.
The 'other cases' refers to situations where I am unable to use flac
on WAV files if the WAV header size is different than the actual file
size. I had to write some fairly complex/kludgey scripts which (among
other tests) flac a file and then use metaflac to examine the size of
the archived file and if it does not exactly match the size of the
original WAV (minus header), discard the flac. Basically, a whole lot
of checking to make sure what is in the archive matches the original.
And very often it does not.
A bug was filed on that a couple years ago but apparently the fix
didn't make it into 1.1.4. If the header says the WAV is only 50
bytes, then flac will only archive 50 bytes and will omit the rest of
a file. Oh, your WAV was 1GB? Sorry, that audio is not part of the
archive. What, you deleted the WAV and only have the flac archive?
Well, I guess you should have noticed the message that indicated your
audio was being discarded:
WARNING: skipping unknown sub-chunk 'PAD '
Yep, that's all the warning you get when flac discards potentially
massive amounts of the original WAV simply because the header doesn't
match the contents.
It sure would be nice if the flac code made a greater effort to
archive the WAV, rather than partials.
Also, I get the legacy wave warning very frequently. It isn't clear
what the issue is there?
All your effort on flac is greatly appreciated.. Sorry to bitch but
these are all pretty serious bugs for some of us who produce original
audio rather than just rip CD collections (never encountered these
bugs doing that), etc. I could try and kludge the flac code but I
doubt my hamfisted approach would pass muster.
Thanks!
FL
"Free Lunch" <freelunch@gmail.com> wrote:> I did a search on the error message and found someone else with a > similar problem and Josh's reply said: > > > but the wave file seems invalid. sample data is supposed to be > > padded to an even number of bytes. > > The gotcha here, as I have tried to explain in similar cases before, > is that we do not live in a perfect world. Many of us record audio > and are unable to control whether a piece of hardware crashes and > leaves the end of a WAV perfectly aligned or padded. In this case the > recorder (Alesis hd24) did not crash, it apparently just doesn't pad. > Since these are original audio masters being backed up, editing them > isn't a viable option.I'll add my vote to this; it would be nice to have an option that would encode these broken wav files. It's a pity some recorders are so badly engineered, but not terribly surprising in our modern world.> A bug was filed on that a couple years ago but apparently the fix > didn't make it into 1.1.4. If the header says the WAV is only 50 > bytes, then flac will only archive 50 bytes and will omit the rest of > a file. Oh, your WAV was 1GB? Sorry, that audio is not part of the > archive. What, you deleted the WAV and only have the flac archive? > Well, I guess you should have noticed the message that indicated your > audio was being discarded: > > 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? 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?> Yep, that's all the warning you get when flac discards potentially > massive amounts of the original WAV simply because the header doesn't > match the contents.You can use the --warnings-as-errors option.> Also, I get the legacy wave warning very frequently. It isn't clear > what the issue is there?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. I'm not sure why, as I know of no program that has trouble with these 24-bit files, and no program besides FLAC that warns about them. Other wave file documentation I've seen -- for example, http://www.sonicspot.com/guide/ -- doesn't include that restriction. I guess this warning could be removed without harm. Regards, Scott / Graue
On 6/10/07, Scott F <graue@oceanbase.org> wrote:> "Free Lunch" <freelunch@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
There are not bugs in flac, they are bugs in your Alesis HD24. What you are asking for are features to be added to flac to fix the bugs in your Alesis. flac is the wrong place to be addressing errors in your Alesis hardware. A better solution would be a stand-alone program which can patch the errors in your WAV files, possibly asking for your choice in which way to do so (there is more than one way, and both are not correct), and maybe even allowing you to audition the samples that are questionable so that you can verify that it is valid audio. The problem with a bad WAV file is that flac cannot decide whether it is better to be inclusive or exclusive when there are inconsistencies. If you're worried about archival, then you certainly don't want automated tools putting bad audio into your backups. I, too, record live and original audio. And I ran into the same problems. In my case, I was recording to AIFF, and there were padding errors. I reported the bugs in my recorder, wrote tools to patch the old audio files, and eventually upgraded with my recorder was fixed by the manufacturer. I suggest that you report these errors to Alesis and see whether they have a firmware upgrade that would make the problem go away. Meanwhile, a standalone tool could repair the WAV files and make flac happy. By the way, the padding that is required is only a single byte. All WAV chunks, whether audio or not, must have an even number of bytes, and be aligned to 16-bit word boundaries. This is only difficult with 8-bit and 24-bit audio, and I assume you are recording at 24- bit. The specification for WAV requires this padding byte, so if Alesis is not generating it, then they are in error. It is a common mistake in both WAV and AIFF file generation. flac could generate better error messages, and Josh is working on this for the padding error. Perhaps you could suggest that he also improve the error message generated when the size in the WAV header is less than the total size of the file. Note, I've seen cases where the header was right, and the excess "audio" data was awful noise generated by some freeware program. I noticed the errors in the waveform overview of my DAW. You certainly don't want flac to be blindly including these bogus audio samples whenever there is an inconsistency. P.S. Are you sure that you aren't using some other program to modify the Alesis WAV files after they are recorded? Perhaps an ID3 tag generator? Some other program may be creating the errors. Brian Willoughby Sound Consulting On Jun 10, 2007, at 07:04, Free Lunch wrote:>> but the wave file seems invalid. sample data is supposed to be >> padded to an even number of bytes. > > The gotcha here, as I have tried to explain in similar cases before, > is that we do not live in a perfect world. Many of us record audio > and are unable to control whether a piece of hardware crashes and > leaves the end of a WAV perfectly aligned or padded. In this case the > recorder (Alesis hd24) did not crash, it apparently just doesn't pad. > Since these are original audio masters being backed up, editing them > isn't a viable option. > > The 'other cases' refers to situations where I am unable to use flac > on WAV files if the WAV header size is different than the actual file > size. I had to write some fairly complex/kludgey scripts which (among > other tests) flac a file and then use metaflac to examine the size of > the archived file and if it does not exactly match the size of the > original WAV (minus header), discard the flac. Basically, a whole lot > of checking to make sure what is in the archive matches the original. > And very often it does not. > > A bug was filed on that a couple years ago but apparently the fix > didn't make it into 1.1.4. If the header says the WAV is only 50 > bytes, then flac will only archive 50 bytes and will omit the rest of > a file. Oh, your WAV was 1GB? Sorry, that audio is not part of the > archive. What, you deleted the WAV and only have the flac archive? > Well, I guess you should have noticed the message that indicated your > audio was being discarded: > > WARNING: skipping unknown sub-chunk 'PAD ' > > Yep, that's all the warning you get when flac discards potentially > massive amounts of the original WAV simply because the header doesn't > match the contents. > > It sure would be nice if the flac code made a greater effort to > archive the WAV, rather than partials. > > Also, I get the legacy wave warning very frequently. It isn't clear > what the issue is there? > > All your effort on flac is greatly appreciated.. Sorry to bitch but > these are all pretty serious bugs for some of us who produce original > audio rather than just rip CD collections (never encountered these > bugs doing that), etc. I could try and kludge the flac code but I > doubt my hamfisted approach would pass muster.
here was a quick hack i put together for same issue, be sure to
back up your files beforehand! unix/linux only obviously ;-)
#
# sfoddfix - Sound File ODD size FIXer
#
# NOTE: flac v1.1.2 pukes on files that have an odd byte count, this pads them
files=${*:-*.wav}
for file in $files
do
size=$(stat --printf='%s' $file)
if [ $(($size%2)) -ne 0 ]; then
echo "size=$size"
echo "echo -e \"\\0377\\c\" >> $file"
echo -e "\0377\c" >> $file
fi
done
> By the way, the padding that is required is only a single byte. All
> WAV chunks, whether audio or not, must have an even number of bytes,
> and be aligned to 16-bit word boundaries. This is only difficult
> with 8-bit and 24-bit audio, and I assume you are recording at 24-
> bit.