Maybe I really do miss something, I really can't understand why this time, only some of the tracks are repeatedly ripped in a non-accurate way. Wheen checking the cue file with CUEtools, it seems there is a complete match of all the tracks. Unaccountably the result is pretty the same: log with overread into LI and LO Then I decided to use another setup, unchecking the "fill up missing offset samples with silence" and, conversely, forcing the drive to read into lead-in and lead-out in order not to lose samples. Here's the log file: log without overread into LI and LO With my first (several) attempts I always got the same result, the first and the last tracks cannot be verified as accurate. As extraction settings I have that missing samples due to drive offset are filled with silence, synchronization between tracks and error recovery quality high. This time it seem there is something different, something wrong, and I would like to understand the origin of this sudden unexpected behaviour.Īs main Drive settings I have used secure mode with 'accurate stream' support (no cache and no C2 errors detection), auto detect drive read command (which turns out to be MMC1, gap detection method A (secure) and read offset correction +103 without "overread into Lead-in and Lead-out. I have always used EAC to rip my CDs (several by the same band), using all the recommended settings for accurate ripping and I have always got quite good results (I also tried once CUEripper which gives the same output log of EAC). The CD is therefore perfectly shiny and flawless, without any marks or scratches. Other than that, it's excellent with tags, and even searches for and attaches album art if you want it to.I have just bought a brand new CD and I wanted to make a rip of it, since I usually listen to my favourite albums through a lossless portable DAC. Basically Picard uses the Disc # tag field instead of changing the Album name to Album (Disc 1) and Album (Disc 2), which confuses Kodi. The only stipulation with Picard is that Kodi doesn't like the way it does multi-disc albums, so I edit them manually in theGodFather (like Excel for tags). The days of "paid for" tag sites is over. CUE sheets are only really necessary for weird albums, like having a "Track 99" hidden track with 80+ tracks silent/missing.Įdit: Adding a vote for EAC still, all these years later. FLAC is a bit-perfect copy as a CD -> single FLAC, and also stays bit perfect to the original disc/track layout in single tracks with a CUE sheet to tell the burner how to splice tracks. Storage is cheap, but processing power is cheaper - nothing has trouble encoding/decoding it these days. It's certainly something to look at.Īll in all, I'd say dbPoweramp is a bit better, but for the cheapskate who doesn't mind experimenting a bit, EAC is hard to beat. In theory this should speed up ripping too, but I don't have any data to know for sure. dbPoweramp supports this command as well. This makes use of the FUA command, originally implemented with Plextor drives but also used by some others, which is essentially a "fast cache flush" command. Another possibility, which I haven't tried because I don't have any drives that support it, is the EAC USEFUA command-line option. For example, the Samsung SH-S223 series of drives do not cache. So for drives for which do not cache data when ripping audio, in most cases you'll get vastly improved ripping speed. Most of the slowdown in EAC secure mode happens with the brute-force way in which it must flush the cache before comparing data from multiple reads. But if you find a drive that does not cache data on audio ripping, as described here, one can get rips that average around 22x speed over the disc in secure mode with EAC. If you uncheck "Eject CD after extraction finished" in EAC options, the test and copy CRCs will be shown in the main EAC window, and it won't be necessary to open the log file to see them.ĭbPoweramp does a much better job ripping quickly with a typical drive than EAC does though. If the disc isn't in the AccurateRip database, and the "test and copy selected tracks" option has been used, it takes only a few seconds to look through the log to compare CRCs of test and copy. In that case, you don't need to look at the log file at all. If it passes AccurateRip, you get a message to that effect in the dialog box that comes up at the end of the rip. I don't spend much time at all looking at log files with EAC.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |