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: Secure Ripper Test (part 2 concise results) (Read 145693 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Secure Ripper Test (part 2 concise results)

Reply #100 –
*whisper* 708a does... =D

Secure Ripper Test (part 2 concise results)

Reply #102 –
Hi Spoon

Just installed R12 and it is working brilliantly! You've created quite a ripper there, well done 

I rip in Ultra Secure mode and I cannot believe the results I am getting. I have just one question, why is there a faded cross next to AccurateRip where "Secure" is displayed next to it with a green tick?

All the best
David

Secure Ripper Test (part 2 concise results)

Reply #103 –
A faded cross means the CD is not in the accuraterip database (when you first inserted the cd it should have said on the totals bar the cd was not in accuraterip).

I read your previous msg before the edit, I take it AccurateRip configured ok?

(whilst I am posting: Alpha 7 has been released, many usablility additions to CD Ripper).

Secure Ripper Test (part 2 concise results)

Reply #104 –
Quote from: spoon on
A faded cross means the CD is not in the accuraterip database (when you first inserted the cd it should have said on the totals bar the cd was not in accuraterip).

I read your previous msg before the edit, I take it AccurateRip configured ok?

(whilst I am posting: Alpha 7 has been released, many usablility additions to CD Ripper).


Yes I re-installed R12, rebooted and it accepted the disks. Not sure what the problem was but it's working great now.

Where can I download Alpha 7? Is there much difference in terms of ripping quality to the one I'm using now? If not I'll just stick with this one for the time being.


EDIT: Found the download link to Alpha 7 but it's not working at the moment.

Secure Ripper Test (part 2 concise results)

Reply #105 –
Quote from: David Lytham on
EDIT: Found the download link to Alpha 7 but it's not working at the moment.


Same here

as Phillip J. Fry would say

“Fix it, fix it, fix it, fix it, fix it, fix it… fix it, fix it, fix it!”

:grins:

Secure Ripper Test (part 2 concise results)

Reply #107 –
The link works in the dbpoweramp forum too now.

Anyone care to explain in exhaustive detail, what the new interpolate option does?

Secure Ripper Test (part 2 concise results)

Reply #108 –
Thanks for the pointer about the link not working (it was only uploaded to 1 of the 2 load balanced servers, hence one try it was there, next it was not).

The interpolate option makes sure that if a frame cannot be recovered, regardless of the information that is given out by the cd drive, it will not cause nasty speaker damaging pops. This is really the option for drives with no c2, if a drive supports c2 then that can be used in a better fashion, which I have yet to write (c2 gives much finer detail of which parts of the frame has problems, so the whole frame does not need to be affected, also the data can be completely replaced in the sub-frame, where at the moment the existing data given out is preserved).

Secure Ripper Test (part 2 concise results)

Reply #109 –
I'm ripping a CD at the moment in Ultra Secure mode. When I put the CD in R12 says "CD is in AccurateRip Database". In the Rip Status column for each track I'm getting a red cross followed by "AR (1)" then next to that a green tick "Secure".

Does this mean all the tracks on this CD were ripped with errors?

Secure Ripper Test (part 2 concise results)

Reply #110 –
That would mean the ripper reported no errors, but the rip doesn't match the one in the accuraterip database.

Since it's a confidence of only 1, and if all the tracks report the same thing, the cd is likely a different pressing then the one in the database.

Secure Ripper Test (part 2 concise results)

Reply #111 –
Spoon,

I would recommend an overhaul of the current CLI plugin in place, especially with the need to specify the extension in a seperate text file.  Something along the lines of fb2k's CLI configuration would be nice; at least an input box where you can specify the extension would be greatly appreciated.

...or is something along these lines planned in the polish / clean-up phase of development, after the bulk of work has been done on the ripper as you bring it to "release" status? 

Secure Ripper Test (part 2 concise results)

Reply #112 –
That is one limitation we cannot get around, ie by the time the compression options are shown, in our Converter the extension of the audio file must be known. That said for all common encoders default install packages will be created, the CLI is being extended to make it programmatical (like the old one) in that an option page like for Lame can be created by adding lines of text to the encoder.txt file (we use it for stdio cli encoders, such as musepack and Neros aac).

Secure Ripper Test (part 2 concise results)

Reply #113 –
Quote from: spoon on
The interpolate option makes sure that if a frame cannot be recovered, regardless of the information that is given out by the cd drive, it will not cause nasty speaker damaging pops. This is really the option for drives with no c2, if a drive supports c2 then that can be used in a better fashion, which I have yet to write (c2 gives much finer detail of which parts of the frame has problems, so the whole frame does not need to be affected, also the data can be completely replaced in the sub-frame, where at the moment the existing data given out is preserved).

Ahah, so you don't use the C2 errors bitmaps yet, while Plextools does 
As for interpolation, did you try enabling the DAP bit of READ_CD command ?

Secure Ripper Test (part 2 concise results)

Reply #114 –
Plextools was written from the stand point where all the drives it works with supports c2, if we had that our code would be / 4, so they have it easy .

The idea of interpolation in the software is that it would be constant, different drives interpolate in different ways, so no longer depending on the drives implementation.

These routines will later be added to a 'Defective by design' profile, which will rip correctly any cds with intentional errors (by correctly I mean without the intentional noise).

Secure Ripper Test (part 2 concise results)

Reply #115 –
None of these new options are effecting how the ripper finds errors correct spoon? just how they deal with erros once they are found, right?  The old alphas still were reporting all the errors hopefully.

If we want all errors found reported and done nothing with, with the new ripper we should not use interpolation and check that they all be reported as errors correct?

thanks spoon, quite an outstanding job

Secure Ripper Test (part 2 concise results)

Reply #116 –
Yes the ripping routine is effectively unchanged, just what is done once unrecoverable errors are encountered.

Even with interpolation, all errors are reported (if complete reporting is selected, even frames which are recovered are reported in that mode).

Secure Ripper Test (part 2 concise results)

Reply #117 –
would interpolation provide the best possible results on a drive that doesn't support C2?

and by best, I mean the least audiable glitches

Secure Ripper Test (part 2 concise results)

Reply #118 –
Quote from: rudefyet on
would interpolation provide the best possible results on a drive that doesn't support C2?

and by best, I mean the least audiable glitches


yes.

Secure Ripper Test (part 2 concise results)

Reply #119 –
I tested this new ripper last night and so far it works real stable and nice. I do have a few questions though.
I'm using a Sony DVD RW DRU-510A.

a.
The drive read cache detected 36KB cache. And the FUA support test said FUA works propper. Also when I enable FUA the cache test says the drive now doesnt cache.
But I've read in thread that the FUA feature is for plextor drives. Is the best option to use for my drive or should i just use the 36KB cache?

b.
My secure settings are: ultra pass 1-6-1, 7800 rereads and c2 enabled.
I have a cd that has 12 tracks that are 'V accurate(5)' en two of them are 'X AR (21) i Secure'.  If I rip those tracks in burst mode they are ripped as 'V accurate(4)! What is better to use and can someone please explain to me what 'X AR (21) i Secure' means?

The log says this:
Code: [Select]
dBpowerAMP Release 12 Alpha 7 Digital Audio Extraction Log from woensdag 18 oktober 2006 5:56

Drive & Settings
----------------

Ripping with drive 'E:   [SONY     - DVD RW DRU-510A ]',  Drive offset: 120,  Overread Lead-in/out: No
AccurateRip: Active,  Using C2: Yes,  Cache: None,  FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Ultra::  Vary Drive Speed: Yes,  Min Passes: 1,  Max Passes: 6,  Finish After Clean Passes: 1
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 700

Encoder: Wave -compression="PCM"

Extraction Log
--------------

Track 7:  Ripped LBA 127682 to 148392 (4:36) in 1:33. Filename: D:\My Documents\My Music\U2\U2 - The Best of 1980-1990 - 07 - Where the Streets Have No Name.wav
  AccurateRip: Inaccurate (confidence 21)   Secure (Warning)  [Pass 1, Ultra 1 to 1, Re-Rip 1 Frames]
  CRC32: ABF87DF7
    Re-rip Frame: 148392 (00:04:36,133) matched 10 / 11

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

1 Tracks Ripped Securely (Warning: sectors had to be re-ripped) (AccurateRip: Different Pressing?)

Secure Ripper Test (part 2 concise results)

Reply #120 –
Is that supposed to be a Check??  Anyways, anytime accurateRip says accurate go with that because its 100 percent.  X AR is when it is inaccurate and the 21 is how many other different hardware rips it was inaccurate with (they all matching that is).  It is odd to me that you get accurate results with burst and not with Secure mode.  Maybe spoon can chime in here...



Quote from: Scidd0w on
I tested this new ripper last night and so far it works real stable and nice. I do have a few questions though.
I'm using a Sony DVD RW DRU-510A.

a.
The drive read cache detected 36KB cache. And the FUA support test said FUA works propper. Also when I enable FUA the cache test says the drive now doesnt cache.
But I've read in thread that the FUA feature is for plextor drives. Is the best option to use for my drive or should i just use the 36KB cache?

b.
My secure settings are: ultra pass 1-6-1, 7800 rereads and c2 enabled.
I have a cd that has 12 tracks that are 'V accurate(5)' en two of them are 'X AR (21) i Secure'.  If I rip those tracks in burst mode they are ripped as 'V accurate(4)! What is better to use and can someone please explain to me what 'X AR (21) i Secure' means?

The log says this:
Code: [Select]
dBpowerAMP Release 12 Alpha 7 Digital Audio Extraction Log from woensdag 18 oktober 2006 5:56

Drive & Settings
----------------

Ripping with drive 'E:   [SONY     - DVD RW DRU-510A ]',  Drive offset: 120,  Overread Lead-in/out: No
AccurateRip: Active,  Using C2: Yes,  Cache: None,  FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Ultra::  Vary Drive Speed: Yes,  Min Passes: 1,  Max Passes: 6,  Finish After Clean Passes: 1
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 700

Encoder: Wave -compression="PCM"

Extraction Log
--------------

Track 7:  Ripped LBA 127682 to 148392 (4:36) in 1:33. Filename: D:\My Documents\My Music\U2\U2 - The Best of 1980-1990 - 07 - Where the Streets Have No Name.wav
  AccurateRip: Inaccurate (confidence 21)   Secure (Warning)  [Pass 1, Ultra 1 to 1, Re-Rip 1 Frames]
  CRC32: ABF87DF7
    Re-rip Frame: 148392 (00:04:36,133) matched 10 / 11

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

1 Tracks Ripped Securely (Warning: sectors had to be re-ripped) (AccurateRip: Different Pressing?)

Secure Ripper Test (part 2 concise results)

Reply #121 –
Quote from: Scidd0w on
a.
The drive read cache detected 36KB cache. And the FUA support test said FUA works propper. Also when I enable FUA the cache test says the drive now doesnt cache.
But I've read in thread that the FUA feature is for plextor drives. Is the best option to use for my drive or should i just use the 36KB cache?
I am thinking it should be ok to use FUA with this drive provided that the cache detection is working properly.  I have a friend with a PX-760A who says that it is being detected as not caching and that the FUA test for this drive was negative, so I'm having some doubts, but I am asking for clarification.  I'm still using a6.  I should upgrade to a7 and test my PX-716A which I'm thinking should be a similar drive.

Quote from: Scidd0w on
can someone please explain to me what 'X AR (21) i Secure' means?
It means that the rip doesn't match what is in the AccurateRip database but was deemed secure by the ripper.  So long as it wasn't the result of a consistent error, the rip is probably good.  How do the rest of the tracks look?
 

Secure Ripper Test (part 2 concise results)

Reply #122 –
I have a question about three different CDs that I have tried to rip.

When I insert the CD, it says "CD in AccurateRip". Then in the "Rip Status" column I'm getting a red cross followed by "AR (then a number here, varies with each track)" then a green tick "Secure".

Sometimes the confidence in brackets is as high as 8 next to the red cross. Could this be that my CD is a different pressing to the one in AccurateRip (I'm in the UK)? How can I be sure that there were no errors? Can I trust the green "Secure" tick?

Thanks
David.

Secure Ripper Test (part 2 concise results)

Reply #123 –
Quote from: David Lytham on
Sometimes the confidence in brackets is as high as 8 next to the red cross. Could this be that my CD is a different pressing to the one in AccurateRip (I'm in the UK)?
Probably, yes.  And if it is, it doesn't matter what the confidence level of the inaccuracy is.  A different pressing is a different pressing.

My general rule is that the confidence of the tracks that are deemed inaccurate should be based on the confidence of the tracks that are deemed accurate and how many of the tracks were ripped accurately.  You should also see how much trouble the ripper had with the tracks that AccurateRip said weren't accurate.

Quote from: David Lytham on
How can I be sure that there were no errors? Can I trust the green "Secure" tick?
So you mean to ask how secure is spoon's new ripper?  I can't answer that but can suggest that you see what EAC does with the track.  Make sure you have it enabled to use null samples in CRC calculations and you can compare the CRCs directly (provided the drive is offset corrected in EAC).

Secure Ripper Test (part 2 concise results)

Reply #124 –
Quote from: greynol on
Quote from: Scidd0w on
can someone please explain to me what 'X AR (21) i Secure' means?
It means that the rip doesn't match what is in the AccurateRip database but was deemed secure by the ripper.  So long as it wasn't the result of a consistent error, the rip is probably good.  How do the rest of the tracks look?

12 tracks that are 'V accurate(5)' en two of them are 'X AR (21) i Secure'.