MediaMonkey forum

We definitely want to have something ready on the upcoming week.

Jiri

Before anyone say anything
Countdown Timer is started.

Thanks guys.

Gentlemen:

Just wondering how the coding is going?

Also, I wanted to confirm with you that we do actually need the new utility to fix these files and that simply using MM to convert damaged FLAC --> new FLAC will cause loss of data?

Thanks.

Andrew

I had high fever last few days
We are not abandon this actually it should be like Jiri Said.

I am very sorry to hear that Peke. I wish you a speedy recovery! Thanks.

Andrew

I uploaded the tool for fixing corrupted FLAC files to http://www.mediamonkey.com/beta/FlacFixTool.zip . Extract it to MediaMonkey\Scripts\Auto folder and after restart of MediaMonkey a menu item will appear in Tools menu for fixing all selected tracks.

Consider it being a beta version, i.e. backup files before you test them and let us know the results. It should be able to fix files incorrectly tagged by MM 2.5.5.996 (at least in most cases).

Jiri

jiri wrote:I uploaded the tool for fixing corrupted FLAC files to http://www.mediamonkey.com/beta/FlacFixTool.zip . Extract it to MediaMonkey\Scripts\Auto folder and after restart of MediaMonkey a menu item will appear in Tools menu for fixing all selected tracks.

Consider it being a beta version, i.e. backup files before you test them and let us know the results. It should be able to fix files incorrectly tagged by MM 2.5.5.996 (at least in most cases).

Jiri

Hey Jiri...

This doesn't mean it could magically restore files that were run tagged multiple times with .996, and then run through .998 and fixed, correct? That is, there is no way to restore the missing frames that would have resulted from multiple occurrences of tagging in .996...?

What specifically does this fix do? You can explain it technically, as I'm sure all of us FLAC-heads here will understand it.

- Tim

Jiri:

Thanks for posting the utility. I will run some tests over the next day or so and post results here.

Is there an easy way to know if the utility was able to repair a given file or not? Is there any way to know if I have lost digital music data in a file?

I have files (most of them) which were re-tagged multiple times with version .996 - it would be nice to know which scenarios this utility will repair and which not?

Thanks again.

Andrew

The utility tries to recreate data in the first audio frame. Tagging by MM 2.5.5.996 overwrote the first 4 bytes by '0' and thus destroyed them. In case the tagging occured only once, destroyed was only the 4-bytes header of the frame and it can be heuristically recreated (almost 100% correctly). However, if the tagging was made several times, more data were damaged and it's impossible to recover them.

I recommend to use the utility in order to try to fix as many files as possible. Then it's probably easiest to download http://www.vuplayer.com/files/audiotester.zip and process all FLAC files - those that are reported as damaged can't be repaired and you should either convert them or rip from CD again.

I hope that it won't cause much trouble...

Jiri

Jiri:

Thanks again for creating the utility. I tested repairing one album (about 8 tracks) this morning and they now all play in Windows Media Player - so it seems to be working (at least for this lmited test).

I do have one question - in the event that a tag had been updated multiple times with version .996, will the repair utility succeed or fail? this is important to know since I will want to re-rip any tracks were I actually lost music data. If the utility repairs all headers irrespective of whether or not music data has been lost then I have no way to know which tracks top re-rip and which to repair.

One idea could be to have an option to choose the conditions when the header will be repaired . . .

Regards,

andrew

I'll try to make it more accurate in recreating corrupted headers, but that entirely depends on how deep corruption is gone.

More statistics on fixing will be shown and hopefully flagging of files that could have loss of Audio data where user repeated tagging several times.

An updated version of the script was uploaded to the same location - the functionality is still the same, but there is more detailed report about tracks that were analyzed.

Jiri

Thanks Jiri:

I will run some tests tonight and post results.

Regards,

Andrew

Two questions:

1) is there any kind of checksum you can run on files who HAVE lost more than one frame of audio data, such that we can know which ones aren't the same as when they were created? That is, is such a checksum created and stored in a known place in a FLAC file, to use for comparison? I re-ran everything through 2.5.5.998, so when I ran it through your fix program (and the test program you provided), everything showed as having no problems... but that doesn't mean they weren't truncated, then "fixed", but still were missing audio data, does it?

2) If not, that means I'll most likely have to rerip my ENTIRE CD collection, since I won't know which files were damaged and then "fixed" (and still missing audio data) and which weren't. If this is the case, will there be any way for me to take, for example, a folder full of an album, and synchronize it's tags on a track-by-track basis, with those of another rip (my original one, for example) of the SAME album, such that tags are copied over and I don't have to manually type in all the tag changes I've made over the last year or so? I don't use just what FreeDB gives me, but make TONS of personalized modifications to account for foreign characters, formatting, etc. Such a synchronization tool would allow you to try to match up tracks, and then copy over the tags from one side to the other (look at the program "Beyond Compare" for a folder and text-file version of such a process).

- Tim