Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: My Linux Ripping strategy with abcde & 2 plextor drives (Read 11321 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

My Linux Ripping strategy with abcde & 2 plextor drives

While I've been using EAC in secure mode with success I was thinking about a way to automate things as I wanted to mass extract my whole CD collection and encode them to FLAC.

Having some previous experiences with cdparanoia I have been thinking about a 2 pass strategy using 2 plextor drives.

My first drive I've been trusting for some time is a Plextor PX-W4012A. Today I acquired a Plextor Premium to test a theory :

Basic ideas :

This is a similar assumption as EAC test & copy : if you read the data twice it should be identical. If there's a read error data it spits out random data so both reads don't compare, then retry until you have consistent results.

- even though both plextors do caching and this is an issue with cdparanoia, reading drives from two different drives to two independent output directories should make the verification quite easy as the cache is not shared across drives

I've modified the "abcde" tool which is a frontend to cdparanoia and flac. By default it bails out if there's no CD in the drive. I changed this script so that it waits until there's a cd in the drive. I created another wrapper script around the modified "abcde" bash script so I can mass rip. It also contains the correct offset values for both drives.

When a cd is finished it is ejected and when a new one is inserted it starts without having to press a key or click.

The idea is to rip a batch in drive A and another in drive B simultaniously, when both batches are finished, swap batches across drives. Then run the rsync tool on both output dirs to spot differences e.g.

Plextor PX-W4012A rips to /data/plex
Plextor PREMIUM rips to /data/prem

comparing is done using

rsync -avnrcI /data/plex/ /data/plex/prem

and will show if there's any differences between both drives. This is the same idea as manually comparing all files using the diff command (but automated  )

Those problematic CD's will probably need manual intervention using EAC for the reread strategy.

This is because cdparanoia will not retry as the data is probably cached in each drive, so if there's a read error, and the sector is reread it will produce the same data from the cache.

The idea is that problem cd's will occur infrequently and as every cd has to be read at least twice, 2 drives will save time and the problem cd's can be solved using EAC.

Caching sidenote :

If there's a way in Linux to disable the drive's caching then both dirs should be always identical unless you'll have an error which can only recovered by one drive (e.g. some nasty scratch which is recoverable on only one drive). Being able to disable the cache would also increase the speed as two drives can securely RIP simultaniously without having to swap batches and the EAC step is avoided even more.

Comments are really appreciated on my first post at hydrogen

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #1 –
Some evolution :

1. I've found a way around the caching issue & cdparanoia

About caching I've changed from cdparanoia as precompiled package to a manually compiled cd-paranoia from source which is included in libcdio.

Changing the readahead to a value corresponding to > 8MB in the source code as described here actually disabled the cache. This change is documented here :

http://www.nabble.com/cdparanoia-and-cache-t2390032.html

One CD that didn't rip identical on both drives during the cache issue (Plextor 4012TA/Premium) now produces less errors with this new patch but still the files are not identical on both drives.

2. Problem disks don't give 100% track quality using EAC in secure mode using the Plexwriter Premium

Using the premium and EAC in secure mode it almost took an hour to complete (compared to 20mins under Linux). One track still had a track quality of 99,99%

3. Do different plextor drives result in different error correction even with EAC ?

I'm thinking about ripping this problem CD (Cafe Del Mar 12 which is still new without any scratches) with EAC on the 4012TA as well. If both drives give also different output with EAC then it is due to the difference in read capabilities between both drives, and my cdparanoia strategy would be good enough for cd's that rip identical on both drives now that the cache issue has been solved.

Some remarks about EAC :

- I don't believe it does batch ripping, you'l need to press F4 for gap detection, shift-F6 for encoding for every cd manually

- it doesn't encode to flac in the background while continuing to rip the next track, which is standard in abcde to flac encoding in the background

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #2 –
Wow, it's cool that someone has finally patched the paranoia libs sources for working propperly also with caching drives  I think it would be great if you comitted a patch to Monty at Xiph, as i remember reading about he had again taken up the job of updating the paranoia libs/cdparanoia. Also, with EAC, then you don't need to detect gaps, unless you want to change the way that the gaps are treated by default i.e. appended to the previous track. Also, if you make cuesheet's, then gap detection are done automatically, as else the info needed to make the cuesheet wouldn't be available. Tycho has made a great AutoIt script called REACT v2.0 which automates many tasks with EAC and other command-line tools, so you can e.g. just press F10 and then ripping and encoding starts automatically to both lossless image or track files + lossy track files + cuesheet + ReplayGain processing etc. Finally, EAC supports on-the-fly encoding from DLL's with MP3 and Monkey's Audio, but other than that, then it also supports queued encoding with all command-line encoders, which resembles on-the-fly encoding pretty much.

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #3 –
Quote from: Martin H on
Wow, it's cool that someone has finally patched the paranoia libs sources for working propperly also with caching drives  I think it would be great if you comitted a patch to Monty at Xiph, as i remember reading about he had again taken up the job of updating the paranoia libs/cdparanoia.


Googling around most people would say that cdparanioa doesn't do error correction with caching drives. This is merely because cdparanoia was designed with drives that had max 1 MB cache in those days (and exhausts the cache of such drives). So it was suggested that by merely increasing the readahead it would bypass even 8 MB caches such as in my Plexwriter Premium.

Now I still need some extra testing to make sure that these claims are true.  If I make a patch then it should be useful for everybody, the -b option doesn't exist yet lets take it

      cd-paranioa -b 8MB

Quote from: Martin H on
Also, with EAC, then you don't need to detect gaps, unless you want to change the way that the gaps are treated by default i.e. appended to the previous track. Also, if you make cuesheet's, then gap detection are done automatically, as else the info needed to make the cuesheet wouldn't be available. Tycho has made a great AutoIt script called REACT v2.0 which automates many tasks with EAC and otherbut command-line tools, so you can e.g. just press F10 and then ripping and encoding starts automatically to both lossless image or track files + lossy track files + cuesheet + ReplayGain processing etc. Finally, EAC supports on-the-fly encoding from DLL's with MP3 and Monkey's Audio, but other than that, then it also supports queued encoding with all command-line encoders, which resembles on-the-fly encoding pretty much.


Even with EAC automation one cd will still take > 1 hour to rip. By default the plextor does 8x CLV and can be changed to much faster CAV but this doesn't really improves my read speed  With cdparanoia it takes like 20 mins.

The only thing I'll still need to do is to test if errors occur in the same sectors both with EAC and cdparanoia after the increased readahead.

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #4 –
I think that your solution is correct, since what you did is what Monty said needs to be done for fixing this issue :

Quote
I'll probably get to it eventually actually; ATAPI finally added packet commands for dealing with cache management on ATAPI drives, just like SCSI always had (but most drives just ignored). ..Or you can increase the cache thrashing constant and rebuild. These days computers have more than 8 meg, it's probably worth doing ;-)


Source : http://slashdot.org/comments.pl?sid=108647&cid=9242997

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #5 –
Quote from: Martin H on
I think that your solution is correct, since what you did is what Monty said needs to be done for fixing this issue :

Quote
I'll probably get to it eventually actually; ATAPI finally added packet commands for dealing with cache management on ATAPI drives, just like SCSI always had (but most drives just ignored). ..Or you can increase the cache thrashing constant and rebuild. These days computers have more than 8 meg, it's probably worth doing ;-)


Source : http://slashdot.org/comments.pl?sid=108647&cid=9242997


With my first attempts (one drive buffering the other didn't) I had a fallout of 1 on 3 cd's which didn't compare. Used an old goldstar CDR drive (which didn't do caching and you'd see the cdparanoia error correction kick in) and a plextor 4012TA with 4MB cache which never showed any corrections at all. This was with the default 1 MB trashing.

So now my fallout should be far less if the cache is trashed up to > 8MB (plexwriter premium has 8MB cache). I'll try to do some new batches on both my plextors to see if I get better results. If uncorrectable errors show up or differences between the Premium and PX4012TA rips with cd-paranoia, these should therefore also be visible with EAC.

Maybe both will interpolate those samples or sectors differently but the positions of those sectors should be at least identical (or same regions on the disk). If this works out then the theory is OK for me and I'll submit a patch.

I'm in the process of going to rip several hundred CD's (my whole collection) and I cannot afford that the extraction is not 100% (quite an audiophile spirit here). I'm not planning to redo it in a couple of years just because audio extraction has improved, it should be just good enought right now no matter what it takes.

EAC is just to slow for me I think I did less then 10 cd's today  (a couple of months to go arrrrggg - not an option)

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #6 –
OK, i understand that you want to test it to make sure  I would recommend that the paranoia libs where modified to use 2MB as read-ahead value, instead of adding a Plextor specific switch which adds 8MB read-ahead value. The cache layer size of a drive isn't the value which is cached during DAE, but only a small part of it. As an example, the Plextor PX-712A and the Plextor Premium2 both have 8 MB cache layers, but they only caches 1171 KB for DAE.
 

My Linux Ripping strategy with abcde & 2 plextor drives

Reply #7 –
Quote from: Martin H on
Tycho has made a great AutoIt script called REACT v2.0 which automates many tasks with EAC and other command-line tools, so you can e.g. just press F10 and then ripping and encoding starts automatically to both lossless image or track files + lossy track files + cuesheet + ReplayGain processing etc.


Another EAC automatic tool to checkout is AutoFLAC, also here at HA.

-brendan