Corrupted FLAC files after tag edit

[Abel]

One vote for the FLAC paranoia setting. There is no repair, once its not a bit perfect copy it has to be reripped, no exceptions.

Note that if the repair tool can repair the file (if tags were only edited once), it is still a bit-perfect copy. If it was repairable it was only a header that was damaged and this header has a fixed value. It is not actually part of the CD data, only part of the FLAC wrapper information.

If the file was tagged several times, then the repair tool will be unsuccesful and it is indeed no longer a bit-perfect copy.

All bets are off if you did a re-encode because that will have stripped out the damaged information and the repair tool will have no use anymore.

Abel

[AerosSaga]

Yes I realize this, and that is unacceptable to me, I have since undertook reripping all I can find, very lame...

[tbessie]

Warning: This is just a guess, I don't know enough details on the Tag synchronization to be sure if this would work, but I want to throw it out there as idea:

Would it not be sufficient to rip the new files to the same name as the old files.

... snipped ...

Abel -- that could work, but the process could be very error- or mistake-prone. If you have 10,000 files, doing that could be tough, especially if, like me, you use a naming scheme that either uses sequential integers as filenames (to keep pathnames shorter -- Windows hates long path names), or trims path components by size, etc.

It COULD work, but would be a much bigger pain, and take longer, and possibly break, than would doing it the way I describe than as a side effect of another procedure.

Just my 2 cents.

- Tim

[Abel]

I agree. It's more error-prone. I was just trying to come up with a way to do it without having to wait for a new release. In my case it's easier anyway since it's only a few files (very happy to be a taggin slacker for once )

Do you automatically rename your files to the numbered filenames? If so you could use the auto-rename on the damaged files to make them stand out and give them more obvious names. You could even match the EAC filenaming convention to match that to avoid most errors.

Abel

[tbessie]

I agree. It's more error-prone. I was just trying to come up with a way to do it without having to wait for a new release. In my case it's easier anyway since it's only a few files (very happy to be a taggin slacker for once )

Do you automatically rename your files to the numbered filenames? If so you could use the auto-rename on the damaged files to make them stand out and give them more obvious names. You could even match the EAC filenaming convention to match that to avoid most errors.

Abel

Good idea, except the damage has already been done. I have renamed and retagged all my FLAC files numerous times, and then run them through the "fixing" procedure, so they are "fixed" but missing audio data. Too late to do anything to note which ones were broken in the first place. I *do* have a few file lists from my first several tries at fixing them based on scripts posted in the Hydrogen Audio forums, but I don't want to depend on those (plus, I have changed the file names since then).

So I will need to rerip EVERYTHING to be sure. I just want to preserve my tag data in the database, and reuse it to apply to the files I rip again.

- Tim

[rusty]

So wrt to my original comments about how to move forward:

For the future, we also plan to:
d) create a script/tool that would allow users to rip tracks to replace existing (corrupted) entries (hopefully for 3.0)
e) add flac 'paranoia' setting (not sure if this will be in 3.0)
f) create a tool to better automate tagging (we have prototype code, but this will probably be post 3.0). Note that 3.0 gives scriptwriters more control in this regard already.

It seems that most of you aren't that interested in d) since you don't want to be tied to MM for ripping. Thus we'd need to instead have some sort of tool to either:
i) export and import tag data into a set of tracks
ii) assign metadata from one set of tracks to another set of tracks
Hopefully this will alleviate the task of updating metadata for newly ripped tracks.

-Rusty

[tbessie]

It seems that most of you aren't that interested in d) since you don't want to be tied to MM for ripping. Thus we'd need to instead have some sort of tool to either:
i) export and import tag data into a set of tracks
ii) assign metadata from one set of tracks to another set of tracks
Hopefully this will alleviate the task of updating metadata for newly ripped tracks.

Exactly -- that's just what I'd love to have at some time.

The folks who have the Ridiculous Accuracy Mania, like me and some others, will generally be ripping with EAC, as you've seen. It's MM's file- and tag-management facilities that we love so much and want to use without having to retag by hand.

I hope there are enough of us out there so that it's worth your time to do this.

- Tim

[Teknojnky]

Thanks for the update Rusty.

I think something like this would be useful for far more people than just us unfortunate folks who got bit by this flac bug.

[Bex]

So wrt to my original comments about how to move forward:

For the future, we also plan to:
d) create a script/tool that would allow users to rip tracks to replace existing (corrupted) entries (hopefully for 3.0)
e) add flac 'paranoia' setting (not sure if this will be in 3.0)
f) create a tool to better automate tagging (we have prototype code, but this will probably be post 3.0). Note that 3.0 gives scriptwriters more control in this regard already.

It seems that most of you aren't that interested in d) since you don't want to be tied to MM for ripping. Thus we'd need to instead have some sort of tool to either:
i) export and import tag data into a set of tracks
ii) assign metadata from one set of tracks to another set of tracks
Hopefully this will alleviate the task of updating metadata for newly ripped tracks.

-Rusty

Actually, there is already a script which could do this. "Copy tags" made by Maaspuck.
http://www.mediamonkey.com/forum/viewtopic.php?t=16044



I'm also working on an update of my dupe script which takes care of this.
It's an extensive update which can copy all tags, playhistory, playcount, date added, last played and playlists entries between tracks in the libaray.
Trixmoto has just joined me in the developing work to further perfect the script. He will add the Album Art copy function and make a proper confirmation dialog in HTML which I don't know how to do.
In fact he has already made the album art copy function but found a issue/bug related to relative paths. He's awaiting a response from Jiri on that matter.

We can release a alpha/beta version of the script like today, if someone is adventurous enough to test it but we should have a stable version within a week. Just let me know and I'll give you the script as it is now.

/Bex

[tbessie]

Actually, there is already a script which could do this. "Copy tags" made by Maaspuck.
http://www.mediamonkey.com/forum/viewtopic.php?t=16044

I'm also working on an update of my dupe script which takes care of this.
It's an extensive update which can copy all tags, playhistory, playcount, date added, last played and playlists entries between tracks in the libaray.

This could be a solution - I'd be concerned that it might not be quite as robust or speedy as something written specifically for the purpose. Also, one question is, does it require that the files one is transferring tags to be files in the library, or can they be just any files in any folder one points to? That second part'd be a requirement for me. That and/or being able to say "associate THIS tag record set in the database with THIS file" (the same as "finding" a file in current terminology, except with more control).

Finally, the above sounds like a multi-step process; a built-in tool might be a smoother experience.

I haven't used the scripts you mention, certainly not their future incarnations , so I can't say whether they'd have what I'd like to see in such a tool. I may try them later, or someone here who's had the FLAC problem can report back and see if they do the trick smoothly and with full control.

- Tim

[Bex]

This could be a solution - I'd be concerned that it might not be quite as robust or speedy as something written specifically for the purpose.

Well, It is developed for the purpose and it is speedy and so far it's robust too but it needs more testing.

Also, one question is, does it require that the files one is transferring tags to be files in the library, or can they be just any files in any folder one points to? That second part'd be a requirement for me. That and/or being able to say "associate THIS tag record set in the database with THIS file"

Yes, both set of files must be in the library. Actually I've been thinking a lot of this and came to the conclusion that it is the best approach. The reason for that is not all tags are supported between various formats but can still be present in the database. You also have explicit database values such as playhistory, playcount, Date Added, Last Played, Playlists entries. Those values would simply be impossible to transfer to a new set of files unless they are part of the library.

Finally, the above sounds like a multi-step process; a built-in tool might be a smoother experience.

The steps are going to be like this:
- Rip the CD and add the tracks to the library
- Select the new tracks and perform a new special search for the old tracks
- Drag & Drop the old tracks to a special node made for the purpose
- Confirmation window pops up. Select desired transfer/copy actions and hit ok
- Done (Well, you might want to auto-organize the new tracks and of course delete the old tracks.)

I haven't used the scripts you mention, certainly not their future incarnations , so I can't say whether they'd have what I'd like to see in such a tool. I may try them later, or someone here who's had the FLAC problem can report back and see if they do the trick smoothly and with full control.

Try it on some copied files and let us know what you think. If you want to test my script as it is now send me a pm and I'll give it to you.

/Bex

[Teknojnky]

My concern with any script based copy tags, is that tags that are not supported directly by MM will probably not get copied.

Tags like MusicIP fingerprinting, Musicbrainz artist/track/release ID's, and whatever other custom tag metadata is out there.

For any copy metadata function to be useful, it must copy _EVERY_ tag, whether it understands it or not.

[Bex]

You are absolutely right Tekno. Unfortunately my script wont be able to do that since I don't now how to do implement it. It should also be difficult to get it to work properly copy tags between various formats (e.g. ID3v1.1-, ID3v2-, APEv2-Tags and Vorbis Comments). And what to do if the destination format doesn't support a field that is going to be copied?

Anyway, I googled some and found out that Mp3tag actually has a copy/paste tag function. It even seems to work between different formats and can be performed on multiple tracks. Check it out and see if it works as expected.

[sunspot]

Is there some reason why MM can't be made to rip as accurately as EAC?

[tbessie]

[EDITED]

Yes, both set of files must be in the library. Actually I've been thinking a lot of this and came to the conclusion that it is the best approach. The reason for that is not all tags are supported between various formats but can still be present in the database. You also have explicit database values such as playhistory, playcount, Date Added, Last Played, Playlists entries. Those values would simply be impossible to transfer to a new set of files unless they are part of the library.

Remember, I'm talking about 2 sets of functionality:

• 1. "Take all the tags in the database which are currently associated with database Record X (and which may or may not be currently associated with File A) and write all tags *which we can* to File B."
  
  2. "Do step number 1, AND change the association of Record X from File A to file B." (i.e. replace the "file" field in the database with the new file.

The steps are going to be like this:
- Rip the CD and add the tracks to the library
- Select the new tracks and perform a new special search for the old tracks
- Drag & Drop the old tracks to a special node made for the purpose
- Confirmation window pops up. Select desired transfer/copy actions and hit ok
- Done (Well, you might want to auto-organize the new tracks and of course delete the old tracks.)

Yeah, that's a bit more involved than I'd like. I'd prefer something like:

• 1. Enter a special "sync mode", which brings up a window where you've got 2 panes. Both panes contain a navigation tree with all the functionality of the main view (searches, filters, etc.) on the left, and a tracklist on the right. The righthand pane, however, will only contain a "My Computer" navigation tree, to assure that the right pane contains actual found files, not database records that may or may not contain file paths in them.
  
  2. I can drag/drop any track or group of tracks to order them, within the tracklist of each pane.
  
  3. Once I am satisfied with the list of database tracks in the left pane, lined up with the list of files in the right pane, I press "go" and the tags (all that can be done) in the left pane are written to the files they are associated with on the right pane.
  
  4. In addition, there may be a 3-state toggle (set of 3 radio buttons, possibly), which would have 1) "do not change database file association", 2) "change database file association", and 3) "add database file association". These would, as listed, (1) not change the file in the database record, (2) change the file in the database record to that of the new track file, and (3) ADD a new record in the database, which is a copy of the old one, but with the newly associated track file. As in a mass-rename operation, files that are *already* associated with a given track could be color-coded as such, as would any conflicts (not sure how that could happen, but it's a possibility).

It's not THAT much more different than your suggestion, just has a slightly different emphasis and feel, I think. I'd have to think about it more to put in more details.

Try it on some copied files and let us know what you think. If you want to test my script as it is now send me a pm and I'll give it to you.

I'll definitely give it a try, to see how it is. I'll PM you in a bit.

- Tim