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: foobar 0.9 vs EAC Secure rip (Read 113378 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar 0.9 vs EAC Secure rip

I guess most of you will know that foobar will now rip CDs using offset correction, and also using a test and copy-like security system (Edit: see [a href=\'index.php?act=findpost&pid=329522\']this post[/a] for an explanation).

I've yet to see any comparisons between EAC Secure rips and those performed by foobar, so I'm starting this thread.

The following are stats from my two drives at home - a Plextor PX-W5224A and a Lite-On SOHW-832S.

As yet the tests are for one CD only, but I intend to post further tests, and also test on my drive at work.  My previous limited test was performed on the drive at work, and discrepancies occurred, so I'm interested to perform a more thorough test on that drive.  It is possible that the earlier beta version of foobar tested may have been an influence.

Edit: FYI I am using 0.9 beta 8.  I only discovered beta 9 was out yesterday, but I intend to stick to 8 for these tests at the moment.

foobar filenames are of the format:

foo-<drive speed>-<security>-<drive>.wav

drive speed : limited | unlimited
security    : disabled | standard | paranoid
drive      : makel of drive


EAC filenames are of the format:


eac-<drive>.wav

EAC rip is in secure mode

MD5s of all files:

3adf5ccf2220532a367ffaf031dd56b3 *eac-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *eac-plextor.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-disabled-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-disabled-plextor.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-plextor.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-plextor.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-plextor.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-paranoid-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-paranoid-plextor.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-standard-liteon.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-standard-plextor.wav

EAC log:

Code: [Select]
EAC extraction logfile from 23. September 2005, 18:06 for CD
Unknown Artist / Unknown Title

Used drive  : PLEXTOR CD-R  PX-W5224A  Adapter: 1  ID: 0
Read mode  : Secure with C2, accurate stream, disable cache
Read offset correction : 30
Overread into Lead-In and Lead-Out : Yes

Used output format : Internal WAV Routines
                    44.100 Hz; 16 Bit; Stereo

Other options      :
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Installed external ASPI interface


Range status and errors
Selected range
    Filename E:\Testing\foobar\eac-plextor.wav

    Peak level 99.9 %
    Range quality 100.0 %
    CRC D26D6311
    Copy OK

No errors occured

End of status report

------------------------------------------------------------

EAC extraction logfile from 23. September 2005, 21:23 for CD
Unknown Artist / Unknown Title

Used drive  : LITE-ON DVDRW SOHW-832S  Adapter: 1  ID: 1
Read mode  : Secure with C2, accurate stream, disable cache
Read offset correction : 12
Overread into Lead-In and Lead-Out : No

Used output format : Internal WAV Routines
                    44.100 Hz; 16 Bit; Stereo

Other options      :
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Installed external ASPI interface


Range status and errors
Selected range
    Filename E:\Testing\foobar\eac-liteon.wav

    Peak level 99.9 %
    Range quality 100.0 %
    CRC D26D6311
    Copy OK

No errors occured

End of status report
As you can see all rips were an exact match.  This was a little surprising following the rips I had attempted earlier at work - but obviously very pleasing.

Until I can test again at work here are the bit-compare results from those rips:

Code: [Select]
Comparing:
file path: "file://C:\DOS\testing\eac.wav" / index: 0
file path: "file://C:\DOS\testing\standard.wav" / index: 0
differences found: 136 sample(s), starting at 581.7864 second(s), peak: 3.051758e-005 at 581.7864 second(s), 1ch
Finished successfully.

Comparing:
file path: "file://C:\DOS\testing\eac.wav" / index: 0
file path: "file://C:\DOS\testing\paranoid.wav" / index: 0
differences found: 1527037 sample(s), starting at 564.3864 second(s), peak: 1.998016 at 567.5842 second(s), 1ch
Finished successfully.

Comparing:
file path: "file://C:\DOS\testing\paranoid.wav" / index: 0
file path: "file://C:\DOS\testing\standard.wav" / index: 0
differences found: 1526901 sample(s), starting at 564.3864 second(s), peak: 1.998016 at 567.5842 second(s), 1ch

Finished successfully.

NB: Length: 9:41.826 (581.826s)
I think that the drive speed was unlimited with the above rips.  I look forward to performing the formal test on the drive, to see the results.

Perhaps I'm being over cautious (paranoid) here - perhaps everyone will just end up posting matching MD5 checksums (if anyone bothers), but I thought it would be good if people could test on various drives using various settings, to prove whether foobar could replace EAC as some users' ripper of choice - or at worst a damn fine alternative (e.g.: CDs that EAC doesn't like for some reason (TRACK1 INDEX 0)).

My next test at home will involve a known troublesome CD.
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #1
Quote
Perhaps I'm being over cautious (paranoid) here - perhaps everyone will just end up posting matching MD5 checksums (if anyone bothers), but I thought it would be good if people could test on various drives using various settings, to prove whether foobar could replace EAC as some users' ripper of choice - or at worst a damn fine alternative (e.g.: CDs that EAC doesn't like for some reason (TRACK1 INDEX 0)).

IMHO it should be the opposite : you could use foobar2000's ripper, instead of EAC burst, for CDs that have difficulty when very scratched.  By the way, try one test with a scratched CD, you should see a difference in results.

foobar 0.9 vs EAC Secure rip

Reply #2
I'm not really sure that's the opposite.  I use EAC's secure mode, and EAC currently (it's on the todo list supposedly) doesn't have test and copy for image files.  Therefore my preferred choice would be EAC secure, then foobar test and copy, then EAC test and copy (tracks).

Can you elaborate regarding the scratched disc?  Are you suggesting the foobar results would be better?

I will try a scratched (or more accurately, badly scratched) CD myself.
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #3
a scratched CD with eac will report supposedly better data than foobar, due to rescanning until CRC match.  However, if a CD is irrecupable, you're better off skipping the error blocks, and filling them with silence instead. -- something both foobar and eac can do, in burst mode.  (or secure for that matter, but it's slower)

foobar 0.9 vs EAC Secure rip

Reply #4
Quote
I guess most of you will know that foobar will now rip CDs using offset correction, and also using a test and copy-like security system (maybe later I can find the link where Peter briefly describes the logic behind foobar's rip).


Where is foobar2000's ripper? I can't seem to find it. I'm guessing that you are using the latest beta from the official site?
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

foobar 0.9 vs EAC Secure rip

Reply #5
Yep 0.9 beta. There are new drive and security settings in the "play audio cd" dialogue.

Then simply use the converter to rip the cd.

foobar 0.9 vs EAC Secure rip

Reply #6
To rip with 0.9 beta.

For the settings: Go to Components > Play Audio CD > Select your drive > Drive Settings > and you can then choose your security level.

To rip the CD: Highlight all your tracks > Right Click > Convert > Convert to > Choose Format > Choose Location.

Are there any plans to generate a log file, or am I missing something? CRC values for the files within the log file would be very nice.
daefeatures.co.uk

foobar 0.9 vs EAC Secure rip

Reply #7
This test is certainly necessery, but I see no reason why I should dump EAC, not even foobar's stricter cue sheet handling made me do that.

foobar 0.9 vs EAC Secure rip

Reply #8
Quote
Are there any plans to generate a log file, or am I missing something? CRC values for the files within the log file would be very nice.

Not that I'm aware of - but I agree it would be good.

I ripped all WAVE files to one directory and then create the MD5 digest using my batch file (which uses FSUM).
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #9
I'm not having much luck finding a difficult disc to test.  I think I may have to make one.  My idea at the moment is to copy the previous test disc and scratch it - that should give me some additional maxims.

It seems to me the best (only useful?) test disc will be one that has recoverable errors (i.e.: errors that don't result in sync errors) - to test the error recovery of both.

I have started tests with REM's "Green" and The Cult's "Love" - both of which I re-ripped when I got my Plextor as I knew I'd had problems when originally ripped with my Toshiba.

Unfortunately both discs have a minor TRACK 1 INDEX 0 track ("pregap") - curiously both TRACK 1 INDEX 1 values are 00:00:33.  I guess this was enough to trouble my Toshiba, but not the LiteOn or Plextor. More importantly it makes them unsuitable for an EAC vs foobar comparison as foobar currently only recognises INDEX 1 values (so the WAVEs will always be unequal even on a perfect rip).

Here's the results anyway, in the continued absense of anything particularly useful:

REM - Green:

3d4345ed37f11170ad72353b0d66b923 *eac-liteon.wav
3d4345ed37f11170ad72353b0d66b923 *eac-plextor.wav
6218b023353db17aad6a73737ea93fb4 *eac-toshiba.wav
9ec150ccd51d2e3c8020e18e6d8056c1 *foo-limited-disabled-liteon.wav
9ec150ccd51d2e3c8020e18e6d8056c1 *foo-limited-paranoid-liteon.wav
9ec150ccd51d2e3c8020e18e6d8056c1 *foo-limited-standard-liteon.wav
9ec150ccd51d2e3c8020e18e6d8056c1 *foo-unlimited-disabled-liteon.wav
9ec150ccd51d2e3c8020e18e6d8056c1 *foo-unlimited-standard-liteon.wav

The Cult - Love:

29cc3412d6227a34031efdaece249691 *eac-liteon.wav
d63b0109535f3fa019d71af9eb621acb *foo-limited-paranoid-liteon.wav
d63b0109535f3fa019d71af9eb621acb *foo-unlimited-disabled-liteon.wav


I'll test the first disc at work tomorrow on the crappy Samsung there, and create an errored version to test as soon as I have time.

Please feel free to post your own tests.
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #10
"Standard" mode already requires two identical CRCs on each block to pass (it will keep rereading and error out if it can't get consistent results after 128 reads; also see console output). "Paranoid" mode is pretty much the same, except it wants four identical CRCs instead; it's absolute overkill and should not be used on anything else than really badly damaged discs such as recent wave of EMI releases (I managed to get an audible glitch with two identical CRCs on Goldfrapp - Supernature on LG GSA-4163; EAC secure mode would entirely refuse to rip it on two different setups).
Microsoft Windows: We can't script here, this is bat country.

foobar 0.9 vs EAC Secure rip

Reply #11
Quote
"Standard" mode already requires two identical CRCs on each block to pass (it will keep rereading and error out if it can't get consistent results after 128 reads; also see console output). "Paranoid" mode is pretty much the same, except it wants four identical CRCs instead; it's absolute overkill and should not be used on anything else than really badly damaged discs such as recent wave of EMI releases (I managed to get an audible glitch with two identical CRCs on Goldfrapp - Supernature on LG GSA-4163; EAC secure mode would entirely refuse to rip it on two different setups).
[a href="index.php?act=findpost&pid=329522"][{POST_SNAPBACK}][/a]


Is there plans to have it output a log?
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

foobar 0.9 vs EAC Secure rip

Reply #12
Quote
Is there plans to have it output a log?
[a href="index.php?act=findpost&pid=329525"][{POST_SNAPBACK}][/a]
Possibly, but there are complications with doing that from architectural point of view. Unless writing info to console (interrupted by playback messages etc) as well as creating separate log for each ripped track is sufficient for you.
Microsoft Windows: We can't script here, this is bat country.

foobar 0.9 vs EAC Secure rip

Reply #13
Argh!  My test CD keeps going from perfectly readable to totally unreadable!

Anyone know of a good way to create (recoverable) read errors on a CD without killing it?

I'm scratching with a bent paper clip at the moment and it goes perfect, still perfect, still perfect, unrecognisable.

As an alternative I will try some restoration on the ones I've totally killed thus far.  I'll buy some Brasso this evening at Sainsburys... I have a Cure CD that has sync errors so I've been waiting to have a pop at that one as well.  Edit:  I just got some at ChavSave at lunchtime but then realised that it won't work on a CD-R!  Ah well, hopefully it will retore my Cure CD.  Any ideas how to restore a scratched CD-R?

Ho hum.

I'm perhaps not the best choice to be starting a testing thread. 

Edit: I think my main problem must be corrupting the TOC, so maybe I'll concentrate more on the outer edge of the data...
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #14
Quote
My previous limited test was performed on the drive at work, and discrepancies occurred, so I'm interested to perform a more thorough test on that drive.  It is possible that the earlier beta version of foobar tested may have been an influence.
<snip>
I look forward to performing the formal test on the drive, to see the results.

The first test did raise some discrepancies, so I decided to run each setup 5 times.  Here are the results:

3adf5ccf2220532a367ffaf031dd56b3 *eac-samsung-2.wav
3adf5ccf2220532a367ffaf031dd56b3 *eac-samsung-3.wav
3adf5ccf2220532a367ffaf031dd56b3 *eac-samsung-4.wav
3adf5ccf2220532a367ffaf031dd56b3 *eac-samsung-5.wav
3adf5ccf2220532a367ffaf031dd56b3 *eac-samsung.wav

7cfc5a09786604963b428a8f4166fb37 *foo-limited-disabled-samsung-2.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-disabled-samsung-3.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-disabled-samsung-4.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-disabled-samsung-5.wav
a7f5a352c22ac4a44f23086fcb29d87e *foo-limited-disabled-samsung.wav

3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-samsung-2.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-samsung-3.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-samsung-4.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-samsung-5.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-paranoid-samsung.wav

3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-samsung-2.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-samsung-3.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-samsung-4.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-samsung-5.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-limited-standard-samsung.wav

3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-samsung-2.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-samsung-3.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-samsung-4.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-samsung-5.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-disabled-samsung.wav

d82232a4bdda3be4db706a5ce19a7d16 *foo-unlimited-paranoid-samsung-2.wav
5abd069a6cfe48392d89abfb8e7de35d *foo-unlimited-paranoid-samsung-3.wav

3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-paranoid-samsung-4.wav
c03b49c3be51f6c55cfbb5121590cbb6 *foo-unlimited-paranoid-samsung-5.wav
c03b49c3be51f6c55cfbb5121590cbb6 *foo-unlimited-paranoid-samsung.wav


3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-standard-samsung-2.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-standard-samsung-3.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-standard-samsung-4.wav
3adf5ccf2220532a367ffaf031dd56b3 *foo-unlimited-standard-samsung-5.wav
4764efd0904d1fb3c2fc6b39e682e9bb *foo-unlimited-standard-samsung.wav


I'm not sure that this is proving anything other than the drive is unreliable.

It's tending toward the fact that limited standard/paranoid is safer, but also unlimited disabled.
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #15
Quote
Unless writing info to console (interrupted by playback messages etc) as well as creating separate log for each ripped track is sufficient for you.
[a href="index.php?act=findpost&pid=329526"][{POST_SNAPBACK}][/a]

Maybe it is an option to pass that data to a simple parser in order to refine the extraction-relevant information?
Infrasonic Quartet + Sennheiser HD650 + Microlab Solo 2 mk3. 

foobar 0.9 vs EAC Secure rip

Reply #16
I ran some tests myself. The disc I used I have previously managed to get consistent extractions (after error recovery) with Plextools in the past and I've not touched the disc since. I'm wondering whether or not the fact that I ripped the disc with other apps first had an effect on the disc by heating it up.
I'll pop it in the fridge and try again later. 

Foobar2000, Plextools and EAC comparison.
daefeatures.co.uk

foobar 0.9 vs EAC Secure rip

Reply #17
Quote
I managed to get an audible glitch with two identical CRCs on Goldfrapp - Supernature on LG GSA-4163; EAC secure mode would entirely refuse to rip it on two different setups.
[a href="index.php?act=findpost&pid=329522"][{POST_SNAPBACK}][/a]

Were they two seperate rips or do you mean Foobar2000 managed to find two identical CRCs during the ripping process?
daefeatures.co.uk

foobar 0.9 vs EAC Secure rip

Reply #18
Quote
Were they two seperate rips or do you mean Foobar2000 managed to find two identical CRCs during the ripping process?
[a href="index.php?act=findpost&pid=329698"][{POST_SNAPBACK}][/a]

Two identical CRCs during single ripping pass. I *did* get a lot of CRC mismatches (rereads) during the process, so it can't be a drive cache issue - unless the drive has done something really weird.
Microsoft Windows: We can't script here, this is bat country.

foobar 0.9 vs EAC Secure rip

Reply #19
Quote
Quote
Were they two seperate rips or do you mean Foobar2000 managed to find two identical CRCs during the ripping process?
[a href="index.php?act=findpost&pid=329698"][{POST_SNAPBACK}][/a]

Two identical CRCs during single ripping pass. I *did* get a lot of CRC mismatches (rereads) during the process, so it can't be a drive cache issue - unless the drive has done something really weird.
[a href="index.php?act=findpost&pid=329699"][{POST_SNAPBACK}][/a]

If I understand what Foobar200 is reporting correctly, the same happened to me above. Something weird is happening, for sure.

edit: for the record a PX-708A (I'll edit my page shortly, I forgot to add that).
daefeatures.co.uk

foobar 0.9 vs EAC Secure rip

Reply #20
Well, I guess there are always very low but non-zero chances of getting same glitched output on bad CD twice. We need C2 support, and I don't have docs or free time for it at the moment.
Microsoft Windows: We can't script here, this is bat country.

foobar 0.9 vs EAC Secure rip

Reply #21
>very low but non-zero chances of getting same glitched output on bad CD twice

That is just it, no one has scientific data to prove it one way or the other, it could be 1:25 of bad rips (where an error got through because of an repeated bad datablock), 1:6, or 1:1000, thing is no-one knows.

foobar 0.9 vs EAC Secure rip

Reply #22
Perhaps a simple test and copy function is enough? C2 doesn't always seem to be reliable either.

edit: I've just ripped the troublesome track 8 on my CD 8 times. Each time Foobar2000 reported that the error recovery was successful, but every file had a different CRC. I'd say some form of test and copy is essential, with EAC aswell as Foobar.
daefeatures.co.uk

foobar 0.9 vs EAC Secure rip

Reply #23
Quote
I ran some tests myself. The disc I used I have previously managed to get consistent extractions (after error recovery) with Plextools in the past and I've not touched the disc since. I'm wondering whether or not the fact that I ripped the disc with other apps first had an effect on the disc by heating it up.
I'll pop it in the fridge and try again later.  

Foobar2000, Plextools and EAC comparison.

I totally missed this post.

Thanks for the info.

I'm beginning to wonder what conclusions can be made - except that each app has it's own way of ensuring security, and none are infallible.

Edit: That said, I'm not expecting results to be the same on badly scratched tracks.  When multiple reads are done I guess it's down to each app to decide how to handle the data it has managed to retrieve from the block in those reads.

Currently I am interested in testing CDs that cause EAC's secure mode error recovery and foobar's standard/paranoid check to kick in, but don't result in read or sync errors (i.e.: recoverable errors).  If foobar and EAC can both agree on the data from recoverable errors then I think that's a real boon for foobar.
I'm on a horse.

foobar 0.9 vs EAC Secure rip

Reply #24
Quote
Perhaps a simple test and copy function is enough? C2 doesn't always seem to be reliable either.

edit: I've just ripped the troublesome track 8 on my CD 8 times. Each time Foobar2000 reported that the error recovery was successful, but every file had a different CRC. I'd say some form of test and copy is essential, with EAC aswell as Foobar.
[a href="index.php?act=findpost&pid=329708"][{POST_SNAPBACK}][/a]

Secure mode was meant to be equivalent of T&C (T&C on per-4MB-block basis, to allow streamed read without caching interfering with rereads), with additional rereads in case of bad CRC until at least two identical results from each sector are read. If you get no read error reports in console, the rip should be as safe as burst mode T&C with no mismatches - assuming the 4MB block read trick works as expected (some drives have more cache than that and actually use it for audio?).
Perhaps something to more aggressively avoid cache is necessary (larger block read size?).
Microsoft Windows: We can't script here, this is bat country.