Better Tag Backup/Restore Options?

[randym]

This post and a post last night (/t/4562/1 )
are the result of my musings on how to avoid ever having to rerip and retag the 250 or so CDs I’ve so far ripped and tagged (75 or them hard-to-tag classical), and the additional 300 or so CDs that are still to go.

It seems that this should be a common concern and that tools would have been developed to address it. But my search of this forum yields little evidence of that.

In any case, I will state my understanding of the tools now available and my thoughts on the ideal tools. My purpose is twofold: (1) To be corrected if my understanding of my current backup/restore options is incorrect/incomplete and (2) To encourage a discussion of useful backup tools and the development of them if I am correct that the current tools are inadequate. On this latter score, I would gladly pay for better backup/restore tools. (So far I have been a leech; but I will ultimately pay my dues to MP3Tag—it is a great tool!)

First, it doesn’t seem to make sense to do new backups of the music files only because the tags have changed. It seems to me to make much more sense to back up the music files only once, and to do updated backups only on the tags.

Tag Backup and Restore Tools Now Available

Florian (/t/2634/1
suggests backing up tags by using “an importable export format.” As I understand it, this strategy runs up against two difficulties: (1) Either (a) you do an tag export for every album, in which case the exports are time consuming and restoring tags would be equally time-consuming, or ( You do an export on a large collection of albums, which would allow a quick backup and restore in the unlikely case of a static directory structure, and would be an unworkable mess if the directory structure changes; and (2) the one line for each track export requirement makes it extremely difficult and time-consuming to backup lyrics (see /t/3635/1 ).

Thoughts on Ideal Tools

1. Be able to select the entire music directory and have MP3Tag create a tag file for each album in the album’s directory with a name such as %artist% - %album%.txt. (If a tag file already exists, a new one is written only if the file modification date on the music files is more recent than the current tag file.) For the lyrics field, a special character would be substituted for the line breaks.
2. Be able to select the entire music directory and have MP3Tag search for tag files that are more recent than the file modification date on the music files, and to import the tags for any such files. For imported lyrics, the line breaks would be reinstated.

My thought is that the tag files would be periodically backed up to DVD (or another hard drive) with the exact same directory structure as the music files (both working and backup). If the music files become corrupted, then it would be possible to first restore the music files, then the tag files, and then tags would be restored only to those music files older than the associated tag file.

This scheme would work if the tag file names are generic---e.g., tag.txt.

Any reactions? Are there tools/methods available now that I am not aware of? Can my ideal tools be improved on?

Thanks,
Randy

[JJ_Johnson]

@randym

This post and a post last night (/t/4562/1 )
are the result of my musings on how to avoid ever having to rerip and retag the 250 or so CDs I’ve so far ripped and tagged (75 or them hard-to-tag classical), and the additional 300 or so CDs that are still to go.

It seems that this should be a common concern and that tools would have been developed to address it. But my search of this forum yields little evidence of that.

I don't really see much point in this exercise if you backup your music files containing those tags.

First, it doesn’t seem to make sense to do new backups of the music files only because the tags have changed. It seems to me to make much more sense to back up the music files only once, and to do updated backups only on the tags.

Maybe if you take that approach to backups of the music files, then you might need something like this. I just update the music file in my backups.

What seems to be the most common method these days for backing up the music library is to simply mirror it on other hard drives or computers, or on external USB drives. The latter is probably the best, given that you don't have to swap too many drives in to complete the backup. Using hard disk based backup and intelligent mirroring software, it's pretty trivial to keep the music files backed up.

[JJ_Johnson]

To expand on the backup question...

I see that in another thread you started, someone mentions using the archive flag, as a traditional backup process might use it.

My opinion is that for backing up an audio library there's virtually zero need for a traditional backup methodology, as might be practiced in a corporate IT environment. A traditional backup approach might employ a father/son or grandfather/father/son backup rotation, and use a mix of periodic full backups and daily differential or incremental backups. These techniques are almost all designed for one purpose - to permit you to recover files or data at_a_particular_point_in_time. Say you accidentally deleted a big portion of a report 9 days ago. You could go back to a previous backup and recover that section of the report.

There's no reason that you'd ever need that type of data protection with the highly static content of a media library. You generally rip the content, add metadata, then never touch the file again. If you do screw or accidentally delete a few tags it's trivial to reenter them. So a mirror backup is the simplest and fastest method.

When I say 'mirroring', note that in no way am I suggesting RAID mirroring for backup purposes. The mirroring should be done manually and only when you're confident that the library is undamaged. For instance, if you accidentally deleted an entire album in a RAID mirror without a real backup, then it's gone. As in forever.

[randym]

@JJ Johnson

I don't really see much point in this exercise if you backup your music files containing those tags.
Maybe if you take that approach to backups of the music files, then you might need something like this. I just update the music file in my backups.

What seems to be the most common method these days for backing up the music library is to simply mirror it on other hard drives or computers, or on external USB drives. The latter is probably the best, given that you don't have to swap too many drives in to complete the backup. Using hard disk based backup and intelligent mirroring software, it's pretty trivial to keep the music files backed up.

Thanks for your thoughts. Given that others have not responded, I guess I was incorrect that others would share my backup concerns.

My concerns are driven by the facts that: (1) I am only now getting started ripping my music and so I am not settled on the tagging conventions I want to follow, (2) I have a fair amount of classical that is difficult to tag and where subjective decisions must be made on how to define an album, and (3) I am perhaps a bit more risk adverse than average.

With regard to (3), I do have backups on an external hard drive. But the hard drive is stored at home along with original copies on NAS, so I have put backups on DVD so I can store them at work. This guards against loss from fire and, more importantly, theft. Perhaps I should invest in an external backup array with internal drives that can be easily removed and stored at work.

Just this Monday I put 30G of classical rips on 7 DVDs. And yesterday I discovered that the replaygain wasn’t done properly on many of the 2-CD sets.

For popular music, the biggest reason tags will change is changes in genre, ratings, and lyrics.

I don’t know much about the type of programming that would go into creating a backup solution of the type I propose, but it is my guess that it would be a fairly trivial exercise for those in the know. If that is true, and if my needs are at all common, it might make sense for those tools to be developed.

If any others out there would like a backup solution of the type I propose, please chime in!

Randy

[studley]

@randym

Thanks for your thoughts. Given that others have not responded, I guess I was incorrect that others would share my backup concerns.

My concerns are driven by the facts that: (1) I am only now getting started ripping my music and so I am not settled on the tagging conventions I want to follow, (2) I have a fair amount of classical that is difficult to tag and where subjective decisions must be made on how to define an album, and (3) I am perhaps a bit more risk adverse than average.

...

If any others out there would like a backup solution of the type I propose, please chime in!

Randy

I have also been looking for this solution. I do a good deal of customization with my tags and every time I try a new music tool I risk having them messed up. I like to experiment... use betas... play with my music and all of the cool new software that is coming out.

While I do have all of my files backed up, this requires a tremendous amount of space (and a significant amount of time especially if I were to need to pull them back off of DVDs). When I change some tags, the last thing I want to do is to have to re-backup all of the changed files when 99% of the file (the music itself) hasn't changed. All the tags from all of my music would take up only a very small fraction of space and could be done much more regularly than backing up the files themselves. Small changes such as ratings and play counts could be included in tags and backed up regularly.

Additionally, I could re-rip my entire collection with a new encoder knowing that I can simply add the information back. With CDs, I essentially already have a HARD copy backup of my collection without the tags.

I believe this is a feature that most people don't know they're missing, but, once they have it will not know how they lived without it.

As far as implementation, one possibility is to name the .tag file based on the audio fingerprint. This would avoid some of the issues with the 'Artist - Track Title' naming structure and the lack of uniformity within it.

I, too, hope to hear from others who may feel this is a valuable addition.

Cheers,
David