INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: Mastiff on June 03, 2006, 07:43:25 am
-
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.
-
If you remove the tags it removes the tags, it has nothing to do with the music data.
-
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?
-
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.
-
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. :)
-
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... 8)
-
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.
-
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...
-
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.
-
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!
-
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.
-
So you have 5 Watertight compartments?
I will wait in the crows nest until an iceberg hits.
-
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! :D Which is what I'm building now, if my two compartments are torn by an iceberg, I still have the lifeboat.
-
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.
-
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.
-
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.
-
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? ;)
-
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.
-
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.
-
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.
-
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.
-
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 :(
-
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.
-
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 (http://www.audioholics.com/techtips/specsformats/CDDVDlongevity.php).
-
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... ;)
-
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 (http://www.cdspeed2000.com/) the dvds and report a quality score. Only a few (http://club.cdfreaks.com/showthread.php?t=170108) support it as yet.
The idea (http://club.cdfreaks.com/showpost.php?p=1373515&postcount=4) 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 (http://club.cdfreaks.com/showthread.php?t=167693) 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, 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.
-
So, this is a typical directory.
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
Lol, i had not even noticed till you pointed it out.
-
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
;)
-
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...
-
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.
-
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.
-
Tags? What tags? ;)
-
Sounds Like Going Parachuting without a parachute
-
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.
-
The ones that get dumped into the comments field.
They Are Valid Id3 tags
-
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...
-
>>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?
-
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!
-
Concur, but what has me stumped are the Artist & Album tags, no difference there ?
-
When a parachute just isn't enough....
(http://www.jriver.com/~jriver/misc/parachute.jpg)
http://www.coolest-gadgets.com/20060531/esg-personal-flying-wings/
-
That was the company that became famous in the 20's for the jackalope, right? ;) Anyway, I can see good use for that in combat situations. The norwegian marinejegerne, sort of a tougher version of your Navy SEALs (flameproof suit on, but they actually win most of the wargames against the yankees, at least the winter wargames - I was CTS (Cosmic Top Secret) cleared communications man in the Navy) could have used those in Afghanistan! So could the first teams of US SEALs and Army Rangers that went into Iraq a few weeks before the actual invasion.
-
Sounds Like Special Forces, Rangers And Delta Force Type Operations. I am sure one day they will come in handy Like D-Day Gliders, And as a matter of fact Tomorrow is D-Day "June 6, 1944 - D-Day"
Today: June 5, 1949 - Dragnet's First Show Was On The Radio
-
Yeah, except for that the gliders had a kill rate of around 30 %...of their passengers! If I remember the number correctly. Many got impaled on branches and stuff, and there were a lot that was shot down. Still, those were a big factor in a successful D Day. That and a Hitler that was a genius when it came to speaking to people, but a babling idiot when it came to strategy! Oh, not to forget the corpse that washed up rather conveniently with papers that pointed to the big invasion happening another place all together. Sneaky, that one!
-
...Going through name tags and stuff used to have a stop of around 10 seconds for each save, now it takes around two!
...The ones that get dumped into the comments field...
I did it a while ago. Erased all comment and some other useless fields (imho song text etc.) with a reliable backup in the backhand. There was no problem to erase them over night. And nothing to win concerning speed (or saving time).
I tried this after realizing my machine was getting slower and slower (now 79'530 mp3 tracks, 427.5 GB, 227.2 Days, Pentium 4 2000 MHz MMX / Memory: Total 523 MB).
Maybe I missed the topic?
-
except for that the gliders had a kill rate of around 30 %
There is one in the museum here in Fayetteville, NC
-
I'd love to see it. I'm pretty interested in WW2. I wasn't before, but then I subtitled at least 50 programs about it for History and Discovery Channel!
-
Sorry for disturbing your discussion.
?
-
Sorry for disturbing your discussion.
?
No problem
Mastiff
here is a link to: Airborne & Special Operations Museum
this page has a picture of the glider
http://www.asomf.org/museum_exhibits_wwii.htm
-
I did it a while ago. Erased all comment and some other useless fields (imho song text etc.) with a reliable backup in the backhand. There was no problem to erase them over night. And nothing to win concerning speed (or saving time).
I tried this after realizing my machine was getting slower and slower (now 79'530 mp3 tracks, 427.5 GB, 227.2 Days, Pentium 4 2000 MHz MMX / Memory: Total 523 MB).
What about less Saving the Database... in the status bar ?
and when writing to files that dont have tags yet.
I don't notice any speedups (nothing significant) in the AA part either after removing the AA specific tags.
The slowdown you mention did not improve after removing song text ? ie bios +lyrics. I recall King splitting his library into 50K songs each to counter this effect, though this would be less desirable. Whole point is to have it all indexable in one place.
If a P4 can't handle that many tracks, what will then ?
-
Hey, a two page discussion that doesn't go a bit off topic isn't much lively... ;) King, those Jeep transports had their own problems. I think around 50 % of the Jeeps needed repairs or had to be discarded after landing. Still, it was the best they had back then, and it did work out pretty well in the end.
-
I haven't followed the whole discussion. Looking at how the discussion goes, I may already be OT, but here is my two cents.
For someone afraid of corrupting music in big tag operations:
you can use MP3BookHelper utility to ensure that the music part of the files have not change during the operation. It can generate a unique number using the music data in the file, which changes if the music data is changed but it doesn't change if only the tags change. It is a fairly easy utility once you set it up, but in a corruption event it will just alert you; so backups are still recommended.
MC hasn't corrupted my music data as of yet (I have been watching out for it for several years), although I use the most recent betas all the time.
-
Not off topic by a longshot. But unfortunately a bit late. Wish I had known about that one yesterday, but now my tags are all removed. On the other side, nothing bad seems to have happened. No error messages that shouldn't bee there or anything. So thanks anyway! Maybe somebody will have good use for that information if they are wondering about the same thing later and find this thread? :)
-
Hmmm, I have all my audio fully tagged.
I do not allow MC to write anything to the files.
I rely upon the library to track plays, ratings, etc.
I too noticed the time spent waiting on file updates and the like.
And, I like tags the way I like the tags.
With MC it is easy to do this.
Would I remove the tags from my files? Naaah, too old-fashioned for that.
In fact, I do cheat a little. I add the MC rating tag to APE files myself. Only the rating. Never saw the need for tool name, version, etc.