[SOLVED] Corrupted flac files after updating tags

[eej71]

Last year I went through a large effort of cleaning up the tags in my flac files. Thanks to the convenient mediamonkey tools, this seemed relatively easy to do especially when it required changing hundreds of files.

It isn't until recently that I have learned that I those edited files are in fact corrupted now. The primary artifact of the corruption is that the first few seconds (where "few" can be as much as 90 seconds) of a song seems to have been dropped. I'm aware of a bug back in 2007? that was subsequently fixed and a tool was provided to fix the affected flac files. My attempts to make use of that tool have failed so far and I suspect my issue is different.

Since I have nearly 30 years of professional experience with C++, this seemed like a good reason to dig into the file format and the FLAC API to see if I could find a programmatic way to repair the broken files.

What's interesting to me is that there is a collection of flac metadata records that appear in sequence.

For example, I see type 0 (STREAMINFO), type 3 (SEEKTABLE), type 6 (PICTURE). But I also see this wacky one - type 127 which is technically not supposed to happen. And it's quite large!

A good flac parser will skip this and then after all these metadata records, then it goes onto find the sync bytes (FF F8?) followed by a well formed header. This is where the flac parser struggles. It ends up skipping a decent number of bytes until it finds a good record.

This is where it gets interesting. That wacky meta data block of type 127... well its quite large... and when I peer inside the guts of that record - there are many sync bytes (FF F8) with what appears to be well formed header bytes after that too. I suspect my missing audio frames is this mystery metadata block.

Does this issue ring a bell with anyone? Has anyone else had this problem lately?

[Peke]

Hi,
No new reports were files after that incident. At that I think I still was handling dev. of FLAC plugin. Can you please open the Support Ticket and or Give us download link to one of files. Also have you been able to replicate FLAC file corruption by tagging a file in MediaMonkey?

[eej71]

Thanks for the offer.

After reviewing the flac file format spec and really digging into my corrupt files, I've come to the conclusion that I don't think mediamonkey is too blame for this. I've noticed that when mediamonkey changes the tags in a file - it usually leaves evidence of that in the Vorbis tags. But in my case, I saw no evidence of mediamonkey touching the file.

I ultimately had two types of corruption.

1) The double flac file. This is where I seem to have two files which are nearly the same concatenated together into one single file. The solution here is to simply peel them apart and in my case I elected to discard the shorter variant which is almost always the first fLaC "blobs" in the file. And then I just retain everything from the second fLaC onward. My brief sampling with flac -t and listening to the resultant file seems to show no evidence of lossage. How did I end up in this state? Beats me!

2) The metaframes of undefined type. The flac file format reserved a handful of metaframe types - 0-8 or so. 9-126 is reserved for future use and 127 is undefined. I have many flac files that have metaframes with a type between 9 and 126. Furthermore, the content of those metaframes - while they have a valid length! - are loaded with actual audio frame data. So I hunt for the first sync byte (0xff 0xf8) in that chunk of unspecified metaframe and then shuffle that out of the metaframe and into the front of the regular frame stream.

I wrote a C++ program to tackle these two scenarios and it has generally been effective. I am likely missing a few audio frames in (2) and in some cases, I see complaints about bad CRCs. I'm willing to live with those rather than rescan the CDs.

The flac data format is ok. I think it was a big mistake not to include a frame length for each audio frame. Instead the spec forces parses into this idiotic hunt for sync bytes. But what do I know.

Bottom line. I think I'm good for now. If there is interest, I can share my goofball C++ program on github should others need to do similar repairs.

[Peke]

Hi,
Your last findings concur with my tests. If you wish you can send me PM with C++ code and sample file for future testings and possible solution if there is more reports. As I am Delphi coder with bare minimum usage of C++ I will just file it under FLAC issues and reports.

In case of further need let me know, we do not go anywhere.

Till then Happy Monkeying!