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: First Public Testing of AccurateRip (Read 14689 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

First Public Testing of AccurateRip

Reply #25 –
so what you're saying is that simply because a drive has the Accurate Stream feature it means that it reads 100% correctly?  um, ok.

<edit> added 'it means'

First Public Testing of AccurateRip

Reply #26 –
Quote
If EAC says a disc is 100% then there is that nagging chance the error returned the same data twice in its 'secure' mode

Use Test&Copy

"Then there is that nagging chance the error returned the same data three times"


Honestly, your project is very nice
But it doesn't do much more than saying 'yes your rip is accurate' or 'no it is not' (right?)
It would allow ripping in a fast mode, and verify the result.

Note: it is important that a CD has been ripped by several people who all find the same hash (sum) before letting the database say 'only this hash is correct'

First Public Testing of AccurateRip

Reply #27 –
Quote
Quote
Your proposing a 2nd seperate system (what EAC tries to do).

Still, adding a decent ripping method (something more advanced then burst mode, cdparanoia maybe?) would be a good thing. That would minimize the amount of bad rips submited.

Remember that those rips will all return different hashes, so no real danger.

First Public Testing of AccurateRip

Reply #28 –
don't get me wrong, I think the idea of having a database of others' results to verify  your own is a great idea, and I appreciate the effort.  I'm only questioning the reading method.  To try and illustrate my point a little better, consider that drives say that they can report C2 information too, but does that mean they report that correctly?  It seems to me that you'll get a much better, bigger, and more reliable database of information, and get better results quicker, if you didn't use burst mode and rely on Accurate Stream to ensure data quality.

First Public Testing of AccurateRip

Reply #29 –
Quote
Remember that those rips will all return different hashes, so no real danger.

Don't you think it would help this effort to have less of these garbage rips though?  Seems to me it would progress quicker and give much more reliable results to compare to if we weren't all ripping in such a hazardous fashion.

First Public Testing of AccurateRip

Reply #30 –
Quote
If EAC says a disc is 100% then there is that nagging chance the error returned the same data twice in its 'secure' mode


This should only be true if you have the incorrect cache settings in EAC.  There is a box labeled 'drive caches audio data' in EAC.  If your drive caches audio data, you put a checkmark beside this box to avoid EAC incorrectly pulling the same read error twice in a row.  If your drive does not cache audio data, you can remove the checkmark.

Quote
If EAC says a disc is 98% you can be sure the disc has errors.


Yes, but the percentage level simply refers to the % of samples that were read without errors.  If your settings are correct, the other 2% of samples were error corrected (read again by EAC) and the rip is perfect.

With the proper settings in EAC, the only time you have to worry is when you see 'read error' or 'synch error' after extraction.

First Public Testing of AccurateRip

Reply #31 –
Quote
This should only be true if you have the incorrect cache settings in EAC. There is a box labeled 'drive caches audio data' in EAC.


Nah, I have seen it myself on two seperate drives that do not cache data (I know). Think about it, why should a scratch always give out different bad results? they can easily be the same.

First Public Testing of AccurateRip

Reply #32 –


It has been reported several times already that the rip could be incorrect even with cache on, even with no errors occured (because CRC mismatch). It has even be reported twice
that with CRC matching, the rip could be wrong (BobHere and Defsiam).

I don't know if a secure mode, that may be very difficult to code, would improve the accuracy of rips very much. We have not enough data about this. Maybe most of burst mode rips are already correct.
On the other hand, CDParanoia, for example, doesn't work on my computer : it doesn't detect errors (see http://www.hydrogenaudio.org/forums/index....=ST&f=20&t=3164 ) .
But one thing is sure, a secure mode would attract users, who otherwise would not care about suffering unsecure extractions now, hoping that in the future, they will benefit from secure ones.

The easiest to do would be a test and copy mode : it would return if errors occured.

Edit : added "maybe most of burst mode rips are already correct"
Edit : added "on the other hand"
Edit : removed "even 100% quality" (not sure to have already see this mentionned)

First Public Testing of AccurateRip

Reply #33 –
i did 2 cd rips test mode, went back to options offset was still at zero, any way to change if i know the offset??? tdk velo 12/10/32a, eac listing showed it as a plextor with+99 offset. il try more cd's tonite when i get home 

First Public Testing of AccurateRip

Reply #34 –
Quote
Now imagine a system that combines both....right now I am trying my best to develop and put everything together for a new concept that has never been tried.

This is a good idea but only works better than EAC by itself once you reach a critical mass of users so that there are multiple samples for CDs outside of the top 1,000.

And if you start off with even slightly less robust ripping than EAC then I would choose EAC instead because it would give me the best rip I can get without borrowing or replacing problem CDs.  Many of the CDs in my collection are imported, out of print, and / or obscure, so borrowing and replacing are not possible.

It's too bad EAC isn't open source, then you could "piggyback" your good idea on top of an existing good ripper (and user base) instead of having to build your own.

First Public Testing of AccurateRip

Reply #35 –
Quote
Which stage did it not yield propper results. Did it Configure? ie find the offset of your drive?


Sorry for the late reply.  I have been away for a while.  I don't know if these are identical versions to the cds that you have in the database, (pressing, later release, etc.) but out of the cds that I had, only one was automatically recognized by your program.  Unfortunately, the disc isn't in very good shape, so I couldn't get identical results.  Because of this, I am unable to setup your program to use accuraterip.

Jordan

First Public Testing of AccurateRip

Reply #36 –
Quote
I publically state that AccurateRip will never be sold off, or charged for. It might even make it onto other Rippers (totally free and open), but that is a little too early just yet.

Integration into EAC would be ideal (most-used audio extractor. EAC offers fast/burst read modes and secure modes. People could do a fast DAE with C2 enabled etc, and check with the accuraterip database afterwards - and switch to a more secure mode if necessary)
I hope we are not going too fast? 

EDIT: I'd like to comment on the AccurateRip idea itself:
many ppl will be glad to finally find their offset 
but the current software (EAC) is so good that you can know 'for sure' whether the rip is perfect or not. (not 100% for sure, but with a accuracy comparable to the AccurateRip database).
Just get the most out of EAC (not in the least the CRC comparison) and the results will be satisfying

The real weak point of EAC is DAE for DCs in bad condition. Read/Sync errors... It tells you the extraction was bad, but you cannot recover data correctly and there's nothing to do about it.

First Public Testing of AccurateRip

Reply #37 –
Quote
Sorry for the late reply. I have been away for a while. I don't know if these are identical versions to the cds that you have in the database, (pressing, later release, etc.) but out of the cds that I had, only one was automatically recognized by your program. Unfortunately, the disc isn't in very good shape, so I couldn't get identical results. Because of this, I am unable to setup your program to use accuraterip.


As soon as someone adds an addition to the database, I will release Test #2 - this will write log files to the disc so I can get a good feel for what is happening. Few days or a week at most.

Quote
most-used audio extractor. EAC


Perhaps around these parts, but looking at freedb it is used as much as dBpowerAMP, CDex is the clear winner:

http://freedb.org/freedb_stats.php?type=we...y&topic=clients

Even with dBpowerAMP alone I think the database will populate quickly (200,000 discs ripped each week).

Quote
i did 2 cd rips test mode, went back to options offset was still at zero, any way to change if i know the offset??? tdk velo 12/10/32a, eac listing showed it as a plextor with+99 offset. il try more cd's tonite when i get home


If it recognised a CD a message would appear offering to find the offsets, after which the title of Audio CD Input will no long say [AccurateRip Unconfigured]

First Public Testing of AccurateRip

Reply #38 –
Quote
Quote
most-used audio extractor. EAC


Perhaps around these parts, but looking at freedb it is used as much as dBpowerAMP, CDex is the clear winner (...)

Yes, of course. But let's be honest:
People who are so perfectionist that copying every single byte correctly is essential to them, well those people don't have any choice: for perfectionists EAC is the way to go (although there is other good software as well, spoon )

-EDIT1- 
the reason I am not mentioning Plextools is because not everyone has a Plextor drive

-EDIT2-
           
          to Pio's reaction on cmyden's post 

First Public Testing of AccurateRip

Reply #39 –
I'm not sure where to post bugs, but I guess this is as good as any...

When determining my drive offset, ARip gives me a +582, where EAC and the Coaster Factory both give me +594. This was using The Cardigans - "Gran Turismo". I also have an Alanis Morissette - "Jagged Little Pill", but ARip didn't recognize it (maybe because it's a German/European version).

First Public Testing of AccurateRip

Reply #40 –
We can look into this one:

1, put your dMC calculated offset into EAC (sample one I think it takes).
Next Rip track 1 'The Cardigans - Gran Turismo' to wave 16bit 44.1KHz Stereo.
2, Convert that Wave file in dBpowerAMP Music Converter to a wave file (Right Click on it >> Convert To >> Wave - press CD Quality button) - EAC writes wave headers different to dMC,
3, Run this CRC calculation program, point it at your converted wave file and write
down the CRC number:

http://www.dbpoweramp.com/bin/Crc32.exe

40KB - will run from web

4, Rip same track 1 with dBpowerAMP Music Converter - Rip to Wave 16bit 44.1KHz Stereo
5, Run the CRC again write down the CRC number.
6, Tell me the CRC numbers.

I have that disc so I will rip track 1 with dMC AccurateRip, EAC and Plextools. We will find out which is the correct offset...

First Public Testing of AccurateRip

Reply #41 –
BTW Alanis Morissette - "Jagged Little Pill" is a protected CD with the TOC messed up, diffrent drives will read different disc lengths.

edit - I was wrong, was thinking of Nat Ibrullia - White lillies island.

First Public Testing of AccurateRip

Reply #42 –
Are you sure "Pill" is a protected CD? That was back in 1995, before Napster, MP3 proliferation and the RIAA turning into an evil monster... 

Anyway, CRC values are:

EAC - 6F9EE721
DBM - 09029A97

...but I think there isn't much one can do with these numbers after all the converting. AND EAC gave me 99.9 in stead of 100% quality, though Test and Copy CRCs were the same.

And whats this about DBM writing different WAV headers than EAC? In what way?

Ah, and I have a LiteOn LTD-163 (without caching).

First Public Testing of AccurateRip

Reply #43 –
hehe i guess i should have read the post on the db forum a little more closer , i dont have any of those cd's lol, guess im the only one who likes metal-hard rock around here lol

First Public Testing of AccurateRip

Reply #44 –
The plot thickens...I ripped the first track.

Quote
ARip gives me a +582, where EAC and the Coaster Factory both give me +594


I am going out on a limb and saying that EAC and Coaster Factory are wrong on the offset, here is my reasoning.

I have a plextor 161040a, an I am 100% sure that the offset is +99 on my drive (dMC EAC and Plextools says it is). I rip that track 1 on my Plextor and the CRC 6F9EE721, same as EAC with +582, so as far as I am concerned the offset is +582, it is a shame that that track has scratches, can you do the same for track 2, or 3 until you get one with no errors and give me CRC results from the small CRC program (I want to see dMC rip right as well).

From SatCPs page Lite-On DVD 16/48 (LTD-163) VGH4N/GH4S Yes (2) No (2) Yes (2) MMC1 (2) +594 (2)  two people with EAC have said 594.


BTW EAC writes an WAVEFORMAT header, dMC WAVEFORMATEX (needed for compressed wave files), it is only 2 bytes different.

First Public Testing of AccurateRip

Reply #45 –
One last thing, set EAC to +594 and rip track 1 and calculate the CRC please.

First Public Testing of AccurateRip

Reply #46 –
It is possible to get a variable offset. Test your drive with Feurio.

Also, it is possible that reading with subchannels changes the offset. It was reported once, but Andre said it was possible for burning only, not reading.

First Public Testing of AccurateRip

Reply #47 –
Quote
          
          to Pio's reaction on cmyden's post 

It was not just CMyden's post, but also all the rambling about the lack of instant secure mode.

By the way, this offset thing is strange. When I detected the true offset of my old drives, I found 12 samples more than SatCPs : http://pageperso.aol.fr/Lyonpio2001/offset.htm  (Yamaha 6416S, found : read from +179 to +185, write -1 ; SatCps reports for the 4416 and 8416 : read from +169 to +171, write from +9 to +13).
Remember that +12 on the read offset is -12 on the write offset.

First Public Testing of AccurateRip

Reply #48 –
spoon:

Your project is great, it's a cool idea. Even better if it works, which seems to be the case. But... FYI... although I will try it out, there's no way I'll use DMC as my main ripping app because of the lack of external encoder support in the free version (I bet many other people think the same - most MPC users on this board I guess, for instance). If the free version had external encoder support, the database would fill up far more rapidly which would make it more useful for all users of DMC, and would ensure that the word gets spread about AccurateRip.

No, I'm not a beggar , just stating my thoughts.

CU

Dominic

First Public Testing of AccurateRip

Reply #49 –
I have been pondering such for a few weeks, it is a shame that the Power Pack is needed for codecs I do not have the time, or am able to write, I will compromise - the Generic Output CLI codec will go free as of 30 minutes from now. The others will follow suit in no more than 4 months.