Topic: Serious FLAC bug found

[it-goes-to-eleven]

I discovered a really nasty flac bug this morning..  I have been archiving some masters and intermediate versions under Linux, compressing them with flac. After compression, I would do a 'flac -t' to verify that the archive was good before removing the WAV file..

Well, flac didn't properly handle some WAV files from recordings that were ended without writing the proper size in the header. It issued a warning but still produced a FLAC file and gave an exit code (0) which suggested everything was Fine.  The FLAC file tested fine. Unforunately, a 1.9GB WAV resulted in a 4KB FLAC file!


So I've reported this bug and I'm sure it will get fixed.. But I will be using gzip for my master archives.

[F.O.Bean]

what version ive had no such problems w/ 1.1.2a

also, id immediately notice if i had a file that was 4KB, and my anal side does each set/show twice in flac frontend anyway, and coming from cd wave>wav>flac frontend ive had really zero problems, those 2 programs like each other!

[it-goes-to-eleven]

what version ive had no such problems w/ 1.1.2a

1.1.1. I'll try a newer version in a bit but I don't think it will make a diff.

I'd been leaning pretty heavily on the flac -t output for verification..  It goes through the whole file and is expected to catch problems that simply looking at file size would not.. But it failed me this time.. It was the small size that gave it away. I am trying to clean up about 10 shows, each with about 4 or 5 versions.

[F.O.Bean]

what version ive had no such problems w/ 1.1.2a

1.1.1. I'll try a newer version in a bit but I don't think it will make a diff.

I'd been leaning pretty heavily on the flac -t output for verification.. It goes through the whole file and is expected to catch problems that simply looking at file size would not.. But it failed me this time.. It was the small size that gave it away. I am trying to clean up about 10 shows, each with about 4 or 5 versions.

whats the flac -t thing you speak of

i verify all of my files and delet input files and fix sector boundary errors, all on the encoding, but that all i do and ive had nothing but great results!

[it-goes-to-eleven]

I really like flac.. This just took me by surprise.

-t extracts the flac file contents without writing the output files.

I suppose I could write a script to flac it, then extract it and compare the original and flac version... That's probably what I'll do.

[RRobar]

he's using the linux version, not the windowz version.

[nic]

whats the flac -t thing you speak of

i verify all of my files and delet input files and fix sector boundary errors, all on the encoding, but that all i do and ive had nothing but great results!

hes using the command line version, not the flac frontend gui

[scb]

what version ive had no such problems w/ 1.1.2a

1.1.1. I'll try a newer version in a bit but I don't think it will make a diff.

I'd been leaning pretty heavily on the flac -t output for verification.. It goes through the whole file and is expected to catch problems that simply looking at file size would not.. But it failed me this time.. It was the small size that gave it away. I am trying to clean up about 10 shows, each with about 4 or 5 versions.

why not just use the -v option when encoding? it'll verify it

[it-goes-to-eleven]

-v also fails.  It produces a bogus flac file and exits with a return code of 0 (implying there were no errors).

[scb]

what's this improper header size?  is flac actually writing the number of bytes the header says to, instead of how many are in the file?

[it-goes-to-eleven]

what's this improper header size?  is flac actually writing the number of bytes the header says to, instead of how many are in the file?

Exactly.  It doesn't check for a discrepency.

[ethan]

I discovered a really nasty flac bug this morning..  I have been archiving some masters and intermediate versions under Linux, compressing them with flac. After compression, I would do a 'flac -t' to verify that the archive was good before removing the WAV file..

Well, flac didn't properly handle some WAV files from recordings that were ended without writing the proper size in the header. It issued a warning but still produced a FLAC file and gave an exit code (0) which suggested everything was Fine.  The FLAC file tested fine. Unforunately, a 1.9GB WAV resulted in a 4KB FLAC file!


So I've reported this bug and I'm sure it will get fixed.. But I will be using gzip for my master archives.

Sounds like a bug with whatever is writing bad headers to me...

[F.O.Bean]

thanks scott, i was like, 'hmmm, ive never seen the -t thing except here at ts.com'

[scb]

what's this improper header size?  is flac actually writing the number of bytes the header says to, instead of how many are in the file?

Exactly.  It doesn't check for a discrepency.

what was the warning you got?

[it-goes-to-eleven]

Sounds like a bug with whatever is writing bad headers to me...

I disagree with shifting this away from being a flac bug. Flac is an archive program that a lot of people rely upon.  It needs to be extremely conservative and fault tolerant in regard to whatever it does. 'do no harm'  Minimally, it should exit and throw an error code.  I'm sure it will get fixed..  The important thing is to be aware of it and remember that the code is a little lazy in this area and may be in others as well..  This type of bug tells me that I shouldn't trust flac for archiving masters.  But intermediate versions, sure.

The header issue happens when digital recorders crash while recording and don't get a chance to update the size in the header. These were laptop recordings.  Since they are masters, I wouldn't normally tweak them.  Since I'm archiving a bunch of shows, I wouldn't normally dig into any particular one (oh, this is the umphreys where my laptop crashed right after the show finished..).

what was the warning you got?

umb.1.wav: WARNING: skipping unknown sub-chunk 'p9'