Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mastiff]

OK, I gotta ask before I try this... I normally use bit by bit compare to make sure nothing has happened to my files, but the problem is of course that if I do that before and after removing tags the bits have changed... So is there much of a chance (forget about failing hardware, that's not gonna happen) that I corrupt the MP3 files while removing tags with MC, or is it just like when changing the tags? I have never, as far as I know, have any files corrupted while tagging.

[KingSparta]

If you remove the tags it removes the tags, it has nothing to do with the music data.

[Mastiff]

But if you remove the tags, doesn't it have to save the full file again? Or does it just change the few bits necessary? Is it only when adding V2 tags to a file that has none it must save the full file again?

[KingSparta]

it just removes the tags

it "may" save the whole file again but it just writes that data it alread has and does not re-encode it, so nothing changes but the tag.

the reason i say "may" is because some id3 tags are padded with extra space this speeds up the write to file because if there is still space in the tag it does not re-write the whole file (to make more room in the id3 tag)

but in both the music data is not changed, that only happens if you re-encode.

[Mastiff]

OK, thanks! Then I'll take the chance and go ahead. A rather large change in my library system, all info's gonna be in the library, with nothing in the files. Then the files won't change when I change info, and I can do a full DVD-R backup of the library (they had Verbatim 100 packs on sale on a local computer shop this week...) and store them in a bank box, or something.

[olarte]

OK, thanks! Then I'll take the chance and go ahead. A rather large change in my library system, all info's gonna be in the library, with nothing in the files. Then the files won't change when I change info, and I can do a full DVD-R backup of the library (they had Verbatim 100 packs on sale on a local computer shop this week...) and store them in a bank box, or something.

Hi Mastiff... I think your backup strategy has a few minor flaws in my opinion.

1. If you already have mp3 tags, they are compatible with any mp3 device, software etc... why remove them so only MC will know what's in the files? Why take the extra step?

2. If you ever veer away from MC (god forbid) or your library gets corrupt, you will loose the info on your files, while if you keep the tags, you can always update the library from tags or the other way around.

3. As for backing up on DVD media, unless you plan to keep it up to date, spend the time to burn at least two copies, and refresh the media avery 2-3 years good luck on the reliability of this media.

INstead now with prices falling, you might want to look at an external usb drive from 60 to 500gb from $80 to $300...

my own strategy is as follows.

Master 250gb drive where I do all my edits, changes etc...

use SyncbackSE (Excellent for easy backups on way syncs etc... $25 for up to 5 pcs) to do the following.

Do a one way backup to 2nd 250 GB drive on another pc at home. This one has a read only share that everyone in my house uses with MC, Ipods etc... they cannot alter the files.

I also do a one way backup to a 500GB Mybook ($250 at Buy.com) which can be my off-site, off-network storage...

The changes take place on one drive, and the backups flow down to one drive for use, and one for safekeeping.

Other than the initial investment, I don't  have to worry about the media, as I have 3 exact copies of the data.

I also trigger the backups only when I want to make sure that I know what I'm backing up. In fact SyncbackSe gives me a log of that It will do before it's actually run.

Hope this helps U...

[KingSparta]

all info's gonna be in the library, with nothing in the files.

sounds like a rather large mistake on your part to me.

so what happens when the mc database becomes corrupt or you decide to go with another player, then you are left with nothing but a mess.

[Mr ChriZ]

I agree with King and Olarte this seems a bit extreme.

You know that using MC's auto library backup system, you can always
restore the library from the last backup, and then perform
an update tags from library, removing any damage you may have
done editing them...

[marko]

interesting.

A few weeks ago, I went through the list at "tools > options > library" and set it so that only [artist], [album], [name], [track #], [date] and [comment] were saved to file. In reality, what else is really needed in there?

I then selected ~15,000 audio tracks and removed their tags, followed by an update tags from library job.

I left each job to run while I slept and all went smoothly. The result is a much snappier MC and I no longer see much of that veeeery annoying "saving tags (1 remaining) / Done saving tag changes" stuff in my status bar.

Everything else is taken care of by a full MC backup every 24 hours, always retaining the last seven backups. Much of everything else is proprietry anyway, so to me, I see my choice as a win/win solution.

[Mastiff]

Thank you, Marko! A brother in arms!

Guys, first: I can't use any other player since no other player supports NetRemote and multi-zone the way MC does. And I don't use and have no plans of using anything along the lines of an MP3 player. I sometimes transfer a few audio books to my PDA phone (XDA Atom with a 1 gig min SD card), but I can do those based on file names. And my kids gets stuff copied to their smartphones (Kevin, 10, has a Qtek 8020 with a 512 meg card and Lisa, 8, has a Qtek 8100 music phone with the same card). They will simply read the filenames when no tag is available. I may actually keep the names, album names and artist names in. I'm in the middle of proof reading my entire library right now (is that anal?), which means that that info won't change either.

Second I do already have a full, identical backup in my carputer, this is just an extra insurance. I don't know where you have the 2-3 year from, but I have some of the first DVD-R that came on the marked (actually making archive copies of those as well right now) around 2002, I believe, and they are just as good as when I burnt them (one exception, but that was because of excessive scratching). And I have ten year and more old CD-R's that still work nicely. The key is buying quality, brand names, not cheap stuff.

One concern for me is the price of storage media, I got 100 4,7 gig DVD-R for around 50 dollars. That means close to 500 megabyte for that price. Let's say 450, for argument's sake. In Norway getting that much hard drive space costs six to eigth times that much. And another thing: A single error kan render the whole drive useless. I've had that happen more than once, but I have totally anal backup habits, so I haven't lost much data. With DVD's you may loose one or two because of whatever, but not the whole batch.

Also like I said I'm doing this so that I can keep the files exactly the same, just change info in the library. That saves me a lot of backups. The only problem with file names and directory names is of course that ? / and a few other special characters won't work, but that's a small price to pay in my opinion. Like Marko I have library backups. I checked today, and I still have backups that are made on MC9! And I upgraded during the beta cycle of MC10. My library is also transfered to the carputer, with the backups, so I can't really see any scenario where I loose that information. That would have to be an earthquake that swallowed my house and car, but then I'd probably be inside since you can't get anywhere out here in the sticks without a car!

[GHammer]

I backup to DVD for long term, have external drive space for near term.
Before backing up to DVD I run FSum in each directory I will backup to create a checksum file.
Then I make a directory listing of files (dir > DVD-xx.txt). Keep a copy on my active drive and leave the original in the burn directory.
Then I use to use WinRAR set to store, not compress, with a 3% recovery record.
I write a DVDs worth via Nero with the verify option.
I test the RARs on the DVD.
I file it away with the others.

The important thing is to make certain you are not backing up bad/corrupt data.
Anytime I change my data (music, whatever) I make ceratin the files are ok then I run FSum against the needed directories. Before my weekly and monthly backups, I verify that the source files have not changed.

I backed up many Gb of corrupt files in the not too distant past. Lazy has its price... On a happy note, I got all new rips done because of that.

[KingSparta]

So you have 5 Watertight compartments?

I will wait in the crows nest until an iceberg hits.

[Mastiff]

GHammer, Interesting! I didn't know about FSum (probably shows that I'm not the nerd people in my neighbourhood think...). I have been using FileSync to do a bit by bit compare, but I assume that FSum is faster. Is there a particular reason why you don't just burn the MP3's instead of RAR-ing them?

King, I prefer to use a lifeboat myself! Which is what I'm building now, if my two compartments are torn by an iceberg, I still have the lifeboat.

[hit_ny]

I'm in the middle of proof reading my entire library right now (is that anal?), which means that that info won't change either.

Curious to know how you will be able to tell all is well with the library, from time to time. I think this is similar to how accountants can tell their books balance but with a double entry system it's somewhat easier

I replaced a few albums recently and noticed something interesting. I gave the new ones the same filenames as the old, and when MC was asleep switched them. When MC woke up, all seemed to be well. Then i did a Locate->Inside Media Center on a few. And the tags that were in the files replaced the ones MC had. It's important to state that only the tags that were in the files replaced their counterparts in the library meaning that library only tags were untouched.

So the file sizes were slighly different (different rip after all), as well as the creation dates than what MC thought, but that Locate triggered something that made MC reread those tags. I'm thinking its similar criteria to what backup programs use to decide whether a backup a file or not.

SO i typed them back in and on repeated Locate->Inside MC folowed by the back button never saw those tags change ever again. I now created backup fields for Album, Name, Artist, Year, Genre so if anything changes i just copy the fields back from backup.

All that to say, that if you make any changes to the fields after discontinuing save to tags. A restore of the media (in case of a crash), followed by a Locate->Inside Media center might restore what was in the files instead of what the library thinks it should be.

I don't at this point think the above behaviour is a bug, but maybe something to consider.

[Mastiff]

You do your replacements differently from me. I do it when MC's still awake. Then I first do "fill tags from library" to get the correct tag info and finally "Update library from tags". That ensures that the files have the correct tags, and that the library has the correct file info (bitrate, length and so on). This hasn't fooled me yet. As for how to know that the library is OK, well, I can't really know, can I? I do every now and then validate it, and I have never lost any files, and I do imports of the directories with my already imported files to see if files has dissappeared from the library, but not from the disc. So far noen of them has happened. I guess it comes down to believing that everything is OK as long as nothing funny stuff goes on.

[hit_ny]

Then I first do "fill tags from library" to get the correct tag info and finally "Update library from tags". That ensures that the files have the correct tags, and that the library has the correct file info (bitrate, length and so on). This hasn't fooled me yet.

Ok, that was a special case, how about making any typo corrections in the future.

According to what you said, you would then save those changes back to the files ? or would that information remain only in the library ?

leading to the situation where there was a slight difference between what is in the media as opposed to what is in the library.

[Mastiff]

That's what I have done so far. Right now I'm in the middle (well, in the first 10 %) of a full proof reading of all track names, album names and artist names. There will of course be typos that escape me, but those will probably be so few that I won't bother to update the backup. Anyway, that will remain in the tag, not in the filename. So if I loose files, I can do update tags from library after I have restored the files from the DVD's. To be honest I never expect to need the backup DVD's. Just like Titanic never expected to need the lifeboats. But what if Titanic had more than enough lifeboats for everybody?

[hit_ny]

Is there a particular reason why you don't just burn the MP3's instead of RAR-ing them?

The simplest i can think of is if the RAR won't open then file is corrupt, instant file modification detection. Whereas if you jsut burn the mp3s there is no way to detect a change in them unless you also include cheksum files.

It's one way to protect integrity of downloaded files too.

[Mastiff]

Right. Still, that may work against you if you have more than one file in each archive, but I think GHammer only has one in each. That has to be a heavy job to rar all those files... I think I will go for FSUM with stored checksum files on the DVD's.

[hit_ny]

So if I loose files, I can do update tags from library after I have restored the files from the DVD's.

So in this case you will actually write to the files then otherwise not.

[Mastiff]

Yeah. But again only the necessary tags (artist, name, album name). Or not... I haven't decided 100 % yet if I want to keep name tags in the files or not.

[hit_ny]

The idea im trying to get at with a library only system is that you never have to write to the files at all. Even if you have to restore from a backup. So long as file locations and names are the same MC will recognise the files and instantly associate any metadata accordingly.

This way checksum files never need to be modified. Your backups & their backups increase linearly as your collection grows and any changes are contained within MC with its library backed up accordingly.

But upto now the safest way to make sure both are in sync, is to write to the files negating all the advantages of a library only system

[Mastiff]

Right. Which is why I'm going back and forth between no tags at all and only name, artist and album name tags. I think I'm gonna fall down on no tags, but I may need to sleep on it.

[glynor]

I'm pretty sure GHammer uses RAR with the recovery record because the RAR Recovery record will sometimes allow you to recover data even if your DVD-R's do suffer "bit-rot" a little and a sector or two are unreadable.

The best thing to do with your optical media to prevent early breakdown is to keep them in the dark.  Light greatly speeds the process that can cause them to "rot" (and it's certainly not a myth, it's happened to me).  Optical discs like to be kept in a cool, dry, dark place.

[Mastiff]

That sounds quite reasonable. I have never noticed the recovery record option of WinRar before. Maybe I should use that too... Come to think of it I have used hkSFV for checksumming, I would assume that this is just as good as any othe hashing method.

As for bit rot, I have seen it on very old CD-R media (like when it first came out), but I haven't really seen it since. Still a good recovery record, (perhaps even 10 %, that should give me a good chance) would probably make this backup even safer.

As for in the dark, this will be stored in a dark, cool place. Inside a metal cabinet. With DVD's of our digital photos. They are backed up in the same way, plus on DVD+RW media, but I want to be even more sure. I know that in ten years a lot of people will be missing a lot of digital photos from the early age of digicams because so few thought about doing backups. There's gonna be some famliy tragedies, I'm sure. "Honey, why didn't you take better care of our wedding photos? Is it because you don't love me as much as your first wife? You still have those wedding photos on paper!"

Oh, and Glynor: Make sure you make the next post perfect! Look at your posting count now...

[hit_ny]

We are straying from your original topic a bit, but since we are talking about DVDs, i recently picked up a writer based on the reviews it got for the sole reason it was able to scan the dvds and report a quality score. Only a few support it as yet.

The idea is it queries how many times error correction would be used by the drive to read during scanning and not necesarily whether it can read it or not (there are other  tests for that). It is also helps to determine which speed to burn a particular media and to compare write quality from different DVD brands. There is a sweet spot with the right combination.

A good scan implies, DVD was well written and less likely to be unrecoverable in the future. This is of course only a small piece of the pie. Goood quality branded media matters (better dyes used so longer lasting), as well as storage in a low humidity environment to lessen rot are just as important.

[GHammer]

GHammer, Interesting! I didn't know about FSum (probably shows that I'm not the nerd people in my neighbourhood think...). I have been using FileSync to do a bit by bit compare, but I assume that FSum is faster. Is there a particular reason why you don't just burn the MP3's instead of RAR-ing them?

Yes, FSum is faster for me. And it can be run from the command line so it is nice for automated tasks like this.

Why not burn directly? Handier to have them in one package (APE/Wavpack, APL files, cue, log) for my purposes. Also, RAR has recovery record ability. ZIP and others do not. So, it is one further insurance policy against corruption. I don't compress, simply store the files inside a RAR. Very fast to create and to unpack.

Is it overkill? Well, I have most of my audio on CD and can rip again when I find I need to. A goodly portion is not available for ripping so if it is damaged it is lost to me. I'll take the extra 3 minutes per CD to give it a better chance of survival.

[GHammer]

So, this is a typical directory.

Code: [Select]

Name            Size Type
CDImage.ape             275 MB Media Center File
CDImage.cue             1.25 KB Image Files
01 - After the Garden.apl                         332 bytes Media Center file
02 - Living with War.apl                         338 bytes Media Center file
03 - The Restless Consumer.apl         345 bytes Media Center file
04 - Shock and Awe.apl         337 bytes Media Center file
05 - Families.apl                         332 bytes Media Center file
06 - Flags of Freedom.apl                         340 bytes Media Center file
07 - Let's Impeach the President.apl                         351 bytes Media Center file
08 - Lookin' for a Leader.apl                         344 bytes Media Center file
09 - Roger and Out.apl         338 bytes Media Center file
10 - America the Beautiful.apl                         347 bytes Media Center file
Neil Young - Living With War.md5                         891 bytes Message Digest Checksums File
Living With War.log       7                  68 bytes Text Document

You see the md5 hash file that FSum creates. I simply use WinRAR to store the entire directory using a 3% recovery record. Then when I have enough, I write all the RAR files to DVD. I have a list of the RAR files contained on each DVD so it is easy enough to get any given file if I need it.

Works for me. Saving the MC library so you could run tag-less would not be much extra effort.

[Mastiff]

What about a utility like hkSFV? It can both calculate with SFV32 and md5sum compatibility, and I have checked for both. What I was planning was to burn DVD's from MC (so I can have a field saying what number DVD the MP3-files are on). But the problem is that then I can't use rar. And anyway, is there a way to tell WinRar to rar every file in subdirectories to a separate file? Having one archive per subdirectory increases the chance for loosing more files per error, doesn't it? It can do this with files in one directory, but not subdirectories, as far as I have found. And it will take some time (understatement) to archive a few thousand directories if I have to do it one by one...

Another thing is keeping the integrity of the library intact. What I am planning to do is to use hkSVF to to one drive at a time (it does the subdirs automatically). Then, when I have added files, I first do a check with hkSVF to see if any files have changed. If no files have changed, I make a new SVF file for that drive, with those added files as well. That would be foolproof, wouldn't it?

[GHammer]

Working from the GUI, under the 'Files' tab, there is an option to put each file in a separate archive.

From Help:

- Put each file to separate archive
Put each selected file or folder to separate archive. If you set this option, an entered archive name is treated only as a destination path for new archives (if it is not a folder, its name part is ignored) and archive names are generated basing on file names.

[Mastiff]

Weird. If I choose a directory with this option, it doesn't work. Say I choose "Albums\Rock"\. If I have a name for the Rar file, it makes one big file. If not, it doesn't even archive.

[Mastiff]

Wait, I get it! If I select several directories I get one archive file per directory. Makes sense... But I suppose it's impossible to get a separate archive for each file in the subdirectories.

[hit_ny]

What about a utility like hkSFV?

I use this and it works great, create a smartlist of files which are sfv complete, drag from MC to hksfv, takes sometime load them up into hfsfv and then it churns away. You need to set hKSfv to use only one instance.

I wish there was a cmd line where i could specify paths in a text file and it works them out from there giving a total at the end, of those passed & failed. They all have a recursive option but that's about it.

[Mastiff]

Yeah, that's one way of doing it. But I have two main music directories, one on each hard drive. So I'm just gonna do hkSFV by itself. Or are there other benefits by doing it in MC that I don't get? This thread is really interesting, btw! At least to me. Lots of good ideas.

[hit_ny]

The only benefit to using from MC is i was working trhough my collectoin and replacing stuff a little at time, so i could not point hksfv to a tree and say check it as there were only specific dirs that were complete.

[Mastiff]

OK, I get it. Most of the stuff I'm gonna do is already set in stone now. Hey, btw, Glynor hitting 1000 and you're hitting 1500 posts. A day for round numbers, methinks! Oh, and I have started removing all tags from the files. Gonna take some time, it seems...

[hit_ny]

Lol, i had not even noticed till you pointed it out.

[Alex B]

Actually, the numbers 1000 and 1500 are nothing special at this forum.

Only 1337 has a special meaning:

http://yabb.jriver.com/interact/index.php?topic=31924.0

[Mastiff]

You know that 1137 gotta be from before I started with computers, 20 years ago! It the term "elite" was used the way we now would use "hacker". Not "cracker", that's a totally different thing. You have to break the law to be a cracker, but not to be a hacker. All though the last group often breaks the law anyway...

[hit_ny]

so what happens when the mc database becomes corrupt or you decide to go with another player, then you are left with nothing but a mess.

If you want to shift to another player it makes even more sense not to write proprietary tags into the files

Shifting to another media manager, would require it to be able to import, given a list and support custom tags for starters. Assuming filenames & paths remain the same, the rest is a question of transforming the MPL to a format the other player can use.

[KingSparta]

If you want to shift to another player it makes even more sense not to write proprietary tags into the files

What tags would they be?

since MC11 uses valid Id3 tags they all should be readable from other taggers.

Now MC9 was another story it did not save some of the data into valid Id3 tags.

[Mastiff]

Tags? What tags?

[KingSparta]

Sounds Like Going Parachuting without a parachute

[hit_ny]

What tags would they be?

The ones that get dumped into the comments field. No way any other player will be able to comphrehend what they mean and vice versa MC won't understand what other players might put in there either.

..and just so we're clear about this, i accept there isn't an std way to do all that MC can do and that it's a compromise. If JRiver want to add compelling features then more strength to them. It's quite common for any sufficiently advanced software to be implementing things that are not even standardised yet.

[KingSparta]

The ones that get dumped into the comments field.

They Are Valid Id3 tags

[Mastiff]

Sounds Like Going Parachuting without a parachute

Not really. More like going parachute with two backup chutes. One in the car and one in a bank box...

[marko]

>>They Are Valid Id3 tags<<

valid, yes, but also proprietry. I did not see any mention of them being invalid.


way to go Mastiff
Do you notice any speed gain in MC?

[Mastiff]

Yeah, I do. Going through name tags and stuff used to have a stop of around 10 seconds for each save, now it takes around two!

[hit_ny]

Concur, but what has me stumped are the Artist & Album tags, no difference there ?

[JimH]

When a parachute just isn't enough....




http://www.coolest-gadgets.com/20060531/esg-personal-flying-wings/