a curiosity, in your collections, you keep the .log file?
Not sure how this is FLAC related but yes. I started keeping logs many years ago when I needed to find CDs ripped with a particular drive and had no logs - forced me to rerip everything just to be sure.
Yes, and I have had some use for it.
Luckily I have not had the use for it that was my first idea to keep them: copying them all into a zip archive is proof to my insurance company of how many CDs I have. (Wrong titles on a lot of the CD singles which cannot be uniquely identified by the TOC, but what the heck.)
There is a lot of information in those log files that is very handy to have. Plus it's super easy to save and keep along with the FLAC image, cue file and album art. EAC makes it pretty easy to keep all of that organized too, as it uses the same file name for each.
JXL
I don't keep a rip log but I do keep a cuetools DB verification log.
Completely useless except for the data track lenght. I keep .accurip & .toc if enhanced CD.
Yet, it's better to keep .log if you don't know how to replace them by .toc
... for me a .log is nothing but a verbose .toc with spam in it.
I only keep the .log as long as I didn't check if the CD is enhanced with Cuetools.
Keeping .log is a fetichism that predates the creation of Accuraterip, when EAC secure rip was mandatory.
I use(d) dBpoweramp for ripping (still missing a few index points every now and then, and there seems to be no way to retro-fix that).
dBpoweramp populates ACCURATERIPDISCID and CDTOC tags, and so I can easily get CUETools to retro-check against AccurateRip. Also, dBpoweramp logs hold the AR info in case I should accidentally delete.
This seems to imply that dBpoweramp users have less need for a log file, and EAC users have a harder time making use for theirs? Is there any EAC log parser that catches data sessions etc and returns the information that CUETools needs?
I don't keep a rip log but I do keep a cuetools DB verification log.
If you use EAC, wouldn't that be part of the rip log - then why generate another?
Keeping .log is a fetichism that predates the creation of Accuraterip, when EAC secure rip was mandatory.
EAC logs include CRC-32s of the uncompressed PCM data of every track. This CRC-32 can be used to verify that the FLAC tracks are genuine - today and tomorrow. When I rip to FLAC, then why shouldn't I take the extra step and go for archival quality by keeping the logs?
If that is a fetichism, then I have a fetich.
At best, it's only usefull if you store in Wav & the rip is not in AR Database. These CRC will tell you if your Wav files are corrupted but it will tell you nothing about the quality of the ripping process. EAC can ouput perfectly valid Wav files with glitches inside if used with Bad settings/Bad CD Drive/Scratched CD.
As you said you use Flac, this is useless. Flac is a robust format, it will tell you the same information if you decode it without error.
No, I verify once ripped or downloaded and if I know it's safe then I'm fine with it and archive/save it to the final folder.
Switching completely to streaming/Spotify after many many many years of offline archiving, it'll be hard but I'm getting there, now I keep a copy only in my networked external drive as an archive backup that I never touch and eventually will delete completely in few years, I've removed everything from the desktop and I may actually even del the desktop and keep just my laptop. Let's see :)
As you said you use Flac, this is useless.
AR/CT to verify the ripping process. PCM CRC-32 to verify the rip now and later because files get corrupted sometimes. EAC logs are very useful.
No, they're not. They're as useful as keeping two .sfv checksums for the same files, it's redundant. Flac already includes checksums. If it is corrupted, decoding Flac will tell you. You don't need EAC logs for that. What you say is only correctif you use plain Wav.
I keep the EAC log, to have a record of the TOC and the used drive incl. the applied offset.
Offtopic: Also I keep the single WAV file .cue to have a record of the INDEX 00 pregaps, the ISRC and the rare PREemphasis flag.
One reason I keep the log file is to keep information on the condition of the CDs that I ripped.
A log file also contains peak levels, which can be handy for distinguishing different masterings of an album.
Just because a log file isn't useful for you doesn't mean it can't be useful for others ... ::)
I usually use foo_dynamic_range for this ...
The thing is ... I am not denying that logs can be handy for some use, as long as you know what you're using it for ... I just try to debuck the myth that .log is mandatory to have a good rip. Nope, it's not. Everything that's inside is either unrelevant for quality (AR is way more reliable) or the info can be found elsewhere (except data track lenght).
Logs are just a centralized place where to get many infos at once on how it was ripped ... and that's all.
If you use logs, just to stare at the line "No errors occurred" thinking your rip is perfect thks to this line because someone told you so in some outdated tutorial then you're doing it wrong.
I manually checked a dozen of non-accurate rips with "No errors occurred" in logs ... after fixing them with CTDB, AR was always right, the rip was flawed (I could ear glitches on some of them).
can be handy for distinguishing different masterings of an album.
Actually, I found rip date to be handy for that. The metadata providers were far from consistent, so I ended up with lots of new and old release dates wrong - but for double discs, I at least knew which belonged together, from having been ripped within minutes of each other.
Turns out that some have picked a disc from here and one from there. Deep Purple: Made In Japan has different releases where the discs "cross over" the masterings, it seems.