MediaMonkey forum

Hi --

I'm currently running MediaMonkey v. 2.5.3.968 with the beta in_flac.dll plugin (though I've also confirmed that this problem occurs with the original version of in_flac.dll).

Updating the tags in a FLAC file that wasn't originally created with MediaMonkey corrupts the FLAC file.

I have example files here:

Before (743K)
After (747K)

Attempting to play the "After" file (on any player) will crash the player. With larger files, the music will sometimes still be playable, but play will start at a random point in the music.

Steps to reproduce:

1) Drag a FLAC file created with another player into the MediaMonkey playlist. (Most of my flac files were created with GoldWave.) "Before.flac", listed above, is a good example.

2) Perform any operation that changes the tags in the FLAC file -- for example, editing a date, or computing replaygain. "After.flac", listed above, had its volume analyzed.

3) If Step 2 doesn't crash the player immediately, attempt to play the updated FLAC file. The player will either crash or start playing at a strange location within the song.

Based on analyzing the "Before.flac" and "After.flac" files with a hex editor, it looks like MediaMonkey is adding 4K of zero padding to the file (presumably to speed up future tag updates). The original GoldWave file had no padding. The actual music data in the corrupted file (everything after the padding) appears to be intact and identical to the original. My guess is that an offset or size value somewhere in the FLAC file isn't being updated, but I'm not familiar enough with the FLAC format to be sure.

Any questions, let me know...

--- Scott

I'll check this out more deeply.
From first look Track Data (Audio Data) isn't coruppted so your FLACs aren't lost.

Will get back to you with more information.

Thanks, Peke!

For what it's worth, I haven't lost any data -- I'm zealous about backups, and I was able to restore my older FLACs. But the bug does kinda limit my ability to update my FLAC tags...

--- Scott

Fixed and will be included in next release.

@unzerpum,
Thank you for support, without your details of problem this would be difficult one. But you have done half work for me and helped me a lot, as you were right only offset was written badly.

Glad I could help!

Hello,

I just noticed this bug report, and I became a little concerned. I bought the lifetime subscription to MediaMonkey a few days ago, and I have been tagging FLAC's with it like crazy, and I'm wondering now if I am going any major problems. Then, the day after my big tagging session, I updated my backup copy of my music files, not having noticed any sign of trouble.

None of my FLAC's were created with MediaMonkey. Most of them were created directly with flac.exe 1.1.2 (called from EAC), but some that I didn't create myself may have been created with other programs. I have gone back and checked some of the FLAC files I've tagged within the last few days by playing them in Winamp, and they seem OK. I've also run some of them through the "flac.exe --test" without error.

I mainly want to confirm that this problem would be detected by running the FLAC file through the "flac.exe --test" option. If so, I can run a batch test on all my recently tagged files and put my mind at ease. With the small "After.flac" provided in this thread, it does report an error, but I'm wondering if it would report an error in the case described where a larger file might still play, but start in the wrong position.

If I do find any corrupted files, would re-applying the tags with the upcoming fixed version, or with another tagger, solve the problem? Also, is there any estimate on when the fix may be available? I've got a lot more tagging left to do, and now I don't know if I should continue!

-- Bill

@Billm
Well most of FLAC Files will be ok expecialy when Encoded by EAC (Flac pplugin was initaly tested with EAC) as eac uses Original FLAC Encoder.
Problem was found when FLAC was created with GoldWave which have abbility to write additional Seek Offesets for playing files which used different Offset write method than MMs. I have fixed it to comply additional offset rules.
And again I say that file itself is not lost just offsets needs to be rewritten.
If needed (when you do not have backups of "corupted" files) it will be easy to fix it (thx to unzerpum debugging skills) so do not worry if accidently happend and you do not have backups (althru you are warned. This is Known Issue in current version, fixed and ready for next version).

fyi, this issue is fixed.

-Rusty