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: EAC 0.99pb1 and AccurateRip reporting (Read 12470 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC 0.99pb1 and AccurateRip reporting

A recent discussion unearthed some dissatisfaction with the new way in which EAC includes AccurateRip information in its status dialog and in its log files:
http://www.hydrogenaudio.org/forums/index....showtopic=55861

The former AccurateRip dll used with previous versions of EAC included the disclaimer, "Your CD disc is possibly a different pressing to the one(s) stored in AccurateRip" in its dialog under certain conditions.  This is no longer the case with the current version of EAC.  Now, when ripping a disc with an ID that has information in the AR database for a different pressing, EAC will say, "Not all tracks ripped accurately" provided that there were no ripping errors.

Some of us feel that this is a step backwards since it is unreasonable to conclude that a rip is inaccurate when a strong possibility exists for there being a different pressing in the database.

Since Andre will soon be working on the next prebeta to address some of the issues that have surfaced, he asked us to come up with a new scheme for reporting AccurateRip results.

As an example, it is my understanding that the previous version of AccurateRip would tell you that your rip might be from a different pressing than the one in the database if at least four tracks were ripped and none of them had a match.

I thought it might be a useful to incorporate EAC data (quality figures, CRC pairs, error messages, etc.) in interpreting the AccurateRip results, but Andre prefers that it remain separate.

Any ideas?

EAC 0.99pb1 and AccurateRip reporting

Reply #1 –
As much as possible, AccurateRip should behave identically in EAC and dBpoweramp. Do the wordings used in EAC originate from dBpoweramp's own feedback system (or otherwise were authored by Spoon)? If so, I think it should continue to follow that precedent. Then, if Andre disagrees with Spoon's wordings, I would encourage him to help in petitioning for improvement.

EAC 0.99pb1 and AccurateRip reporting

Reply #2 –
Previous to EAC .99 and dBpoweramp R12 accuraterip its self controlled the wording, now the programs can generate their own wording.

In R12 unless logs are displayed there is no wording, it is all graphics on the screen. EAC .99 seems to create all wording internally, most is similar to existing, so no real problems there.

Where there are text output, it should be uniform, otherwise it would fragment accuraterip and make it more confusing.

EAC 0.99pb1 and AccurateRip reporting

Reply #3 –
Can you tell us what messages you use in the logs and what the criteria is for displaying them?

I realize you feel that dBpowerAMP is more secure than EAC and might be opposed to tayloring messages based on whether the results were deemed secure in EAC because of this, but knowing the methodology should be helpful in improving EAC's messages nonetheless.

EAC 0.99pb1 and AccurateRip reporting

Reply #4 –
Quote from: spoon on
Where there are text output, it should be uniform, otherwise it would fragment accuraterip and make it more confusing.

Well, how I've understood what Andre says in the release thread, he had to rely on non textual feedback from the AccurateRip.dll in order to be able to write something to the EAC log. But the downside of only getting the raw results is that he has no access to the logic in the AR.DLL that decides what to tell and suggest to the user and that he has to make up his own, which is basically very simple: non-AR-match=non-accurate-Rip and AR-match=accurate-Rip as far as I can see.

If he doesn't know exactly what logic the DLL uses when it generates the (pre-0.99-style) text messages which he can't use for his log for some reason, then he can't be uniform.

PS: Here are the first real "suggestions" in the above mentioned thread. They're not "guesses" how AR works but "suggestions" for EAC. If anyone wants to comment on them I'd say rather do it here, since that's what Andre suggested to do and greynol started this thread for... 

http://www.digital-inn.de/125671-post25.html
http://www.digital-inn.de/125683-post26.html

PS2: First I'd rather want to know how AR exactly works when it puts out text messages before wanting to discuss how EAC should interpret the AR results. Because I agree that all applications that make use of AR should have consistent text output, not necessarily exactly the same text strings but semantically and logically the same meaning.

Then I hope we can improve the semantic output of all applications that make use of AR because I think it should and it can be improved. I fear there are some inconsistencies in how the AR.dll interpretes the test results, thus giving out a false conclusion about the rip quality to the user. I'm sure this can be solved by discussing every possible ripping/result-scenario we can think of or have encountered, and by evaluating here what we saw and experienced with the best possible technical logic and reason.

EAC 0.99pb1 and AccurateRip reporting

Reply #6 –
Quote from: greynol on
I'd prefer that people read this post from me:
http://www.digital-inn.de/125652-post18.html

Quote
A cool trick you can play is to tell AccurateRip to use a different offset so that your disc matches a different pressing with the same ID. I've been able to verify that some of my tracks (not to mention entire discs) were ripped correctly this way.


I've got a general question about differing pressings. From the above observation of yours I take it that a "different pressings" means a different offset during the creation of the CD's glass master, right? That's probably also the reason why people occasionally get wrong offset corrections for their drives from AR setup tests.

But now I'm wondering is it possible for two differing pressings to have partial mismatches and partial matches? I guess the TOC is used as the basis for the AR's "disc id", isn't it? What if two pressings with the same TOC but far more severe differences than just an offset skew exit? Maybe some mastering glitches, digital silence instead of music in some samples whatever...

EAC 0.99pb1 and AccurateRip reporting

Reply #7 –
Quote from: Fandango on
That's probably also the reason why people occasionally get wrong offset corrections for their drives from AR setup tests.
Indeed.

It's possible that another pressing with the same AR Disc ID may differ by more than a simple offset, but this usually isn't the case.

EAC 0.99pb1 and AccurateRip reporting

Reply #8 –
Quote from: greynol on
It's possible that another pressing with the same AR Disc ID may differ by more than a simple offset, but this usually isn't the case.

I see. But although this seems to be very rare, we have to keep this in mind because it can have quite an effect for the affected CD albums. I wonder if there's any detection of such pressings implemented in AR...

EAC 0.99pb1 and AccurateRip reporting

Reply #9 –
I only blindly trust AR when it says a rip is accurate and I don't submit results  from rips done with incorrect offsets (though this shouldn't matter unless it knocks good data out of the database).

EAC 0.99pb1 and AccurateRip reporting

Reply #10 –
AccurateRip can handle totally different audio samples, for 2 cds with identical TOCs, ie two very different crcs. There would be 2 crcs in the database.

AccurateRips wording has to be kept as simple as possible, the more the program tries to 2nd guess an inaccurate rip, the more it will get it wrong IMHO. The only intelligence needed is the different pressing suggestion, when there are 4 or more tracks all inaccurate.

EAC 0.99pb1 and AccurateRip reporting

Reply #11 –
IMHO, it is YHO that matters most here.  FWIW, I agree with you about second guessing being a bad idea.

Thanks for verifying 4+ all inaccurate for different pressing message.  Would it be ok with you if this were implemented in EAC?

Fandango, would this ease your concerns?  Cosmo?  Anyone else?

EAC 0.99pb1 and AccurateRip reporting

Reply #12 –
As I already said I agree that the AR report in EAC's log should be congruent to the one in other application's logs like dBpoweramp. Not necessarily the exact same text strings but semantically the same meaning. Andre needs that freedom for tailoring a consistent log output design and AR results in EAC's log will have to be translated in many languages, too. I like the "is [%s] but should be [%s]", btw.

About the threshold of at least 4 differing tracks, I don't know, what's the decision in favor of this number based on? Is it a guess? If so it's still better than no such message at all. 

But as I also said before somewhere else it's illogical to say "Rip not accurate" and also saying "probably a different pressing" at the same time. It's like saying "This guy's alibi cannot be confirmed, so he did commit some crime. Although we have to admit that maybe he's not the guy we are looking for, but we say he's guilty anyway.". If it were a different pressing and it's not in the database, then AR cannot know whether it was "not accurately ripped" and in a kind of way it admits that it can't be sure with the "different pressing" message, which honestly is plain weird. That simply makes no sense. I don't know how you can make a difference in EAC and still be compatible to the semantics of the AR.dll's message output. Maybe a third section at the end? A conclusion that takes notice of perfect results from EAC's own secure mode? Or boldly breaking the compliance to AR's output and get rid of these "not accurate" claims in the AR section itself? That's up to Andre.

I'm neither a statistician nor an engineer familiar with Audio-CD production but I do think it is possible to proof in some cases that a rip went wrong with data from the AR database, but such an analysis will never be implemented in AR.dll it seems. But if someone with the skills is willing to do it he has my support. Maybe a good subject for a thesis or paper.

My personal opinion is as follows: Exchange "not accurate" with "unknown" in the AR.dll itself and everything's fine because you're on the safe side not claiming anything that can be false. But if dBpoweramp devs don't want to budge, then dump the compatibility to AR message output and change it in EAC's language files. That's what I would do if I were to make use of AR in my program because I would hate to explain this matter to every newbie that notices it and comes around to complain.

EAC 0.99pb1 and AccurateRip reporting

Reply #13 –
With a 3 track singles cd, it is quite easy to have scratches on all tracks, it is even possible on a 10 track disc.

If pressings did not exist, then accuraterip could convey 100% is a rip was accurate or inaccurate, unfortunately they do exist.

EAC 0.99pb1 and AccurateRip reporting

Reply #14 –
Hm, I'm wondering if there really is no way to identify different pressings. If this was possible, it would indeed make new functionality possible and solve so many problems with online CD databases like AccurateRip or freedb.

I've looked at this ARCue.pl script in order to see how the AR disc ids are created and as far as I understood it the TOC or rather track offsets are the sole basis for identification. That's sufficient for standalone CD-players in order for them to seek to the desired tracks, but optical computer drives can do so much more than that. And maybe it's enough to get what we want?

Now I've heard about this guy IpseDixit and his still mysterious super-ripper called "PerfectRip", that will be able to accurately measure the main/sub-channels skew for a really perfect 1:1 copy. Some of the functionality of "PerfectRip" is already implemented in his previous set of tools, called "xpert tools", but I doubt the channel skew detection is. Anyone with some knowledge can (should) have a look:

Announcement: http://club.cdfreaks.com/showthread.php?t=197568
Direct download link: http://spanish.doom9.org/Soft4/Audio/Xpert_tools.rar

It seems to be able to do all kings of fancy stuff, but what I'm actually imagining is to use this sub-/main-channel skew to identify different Audio-CD pressings, it should be unique for every glass master depending on what machine made it and how the machine was set up. Does anyone else think this might be worth investigating? I'm curious what IpseDixit might have to say about this matter.

EAC 0.99pb1 and AccurateRip reporting

Reply #15 –
Quote from: Fandango on
Quote from: greynol on

I'd prefer that people read this post from me:
http://www.digital-inn.de/125652-post18.html

Quote
A cool trick you can play is to tell AccurateRip to use a different offset so that your disc matches a different pressing with the same ID. I've been able to verify that some of my tracks (not to mention entire discs) were ripped correctly this way.


I've got a general question about differing pressings. From the above observation of yours I take it that a "different pressings" means a different offset during the creation of the CD's glass master, right? That's probably also the reason why people occasionally get wrong offset corrections for their drives from AR setup tests.


Hey! Why not just re-check a rip over and over again each time shifting the offset a bit? If there's a match after some tries, we know for sure that we got a different pressing! It's a bit computationally intensive but if we do it with only one track (i.e. the shortest one), maybe not that slow after all...  The benefit would be awesome.

PS: This has gone quite off-topic now...  sorry.

EAC 0.99pb1 and AccurateRip reporting

Reply #17 –
Sounds interesting, can you elaborate how that works?

EAC 0.99pb1 and AccurateRip reporting

Reply #18 –
I played around with dBpowerAMP some since my last post and have made this observation:

dBpowerAMP will suggest the possibility that your disc is from a different pressing so long as it found no AR matches and so long as there no re-reads performed regardless of the number of tracks ripped.

Quote from: Fandango on
I like the "is [%s] but should be [%s]", btw.
This may be helpful, but if you have a different pressing, then how would AR know what CRC it should be?
Furthermore, if there is more than one pressing in the database, how would AR know what CRC it should be?

I would propose that it say, "is [%s1], but AccurateRip returned [%s2]."

I also propose that EAC not substitute any AR summary messages for ones that it would generate had AR not been used.  If EAC determines that "no errors occurred" then it should continue to say this just after the AR summary.

Quote from: Fandango on
My personal opinion is as follows: Exchange "not accurate" with "unknown" in the AR.dll itself and everything's fine because you're on the safe side not claiming anything that can be false.
I agree 100%!

How about replacing
"not ripped accurately"
with
"cannot be verified as being accurate"
for each individual track?

I still like the idea of adding the disclaimer that there may be a different pressing when AR cannot verify any tracks but have a problem with choosing an arbitrary minimum number of tracks to be ripped.  I think it's also worth mentioning that the previous AR dll uses four as this number regardless of the actual number of tracks that are on the disc being ripped.  In light of this and in light of the fact that dBpowerAMP makes no distinction how many tracks are ripped, I propose that there be no minimum requirement.

How about replacing the summary statement
"Not all tracks ripped accurately"
with the options
"Some tracks could not be verified as accurate"
or
"No tracks could be verified as accurate. You may have a different pressing from the one(s) in the database"
and putting it just before "No errors occurred" when EAC detects no errors?

When EAC does detect errors, how about the options
"Some tracks could not be verified as accurate"
or
"No tracks could be verified as accurate"
without the ". You may have a different pressing from the one(s) in the database" part?

EAC 0.99pb1 and AccurateRip reporting

Reply #19 –
Quote from: greynol on
dBpowerAMP will suggest the possibility that your disc is from a different pressing so long as it found no AR matches

That makes sense to me, since most if not all differing pressings just have an offset skew of the audio mainchannel, which will result in a no-match for the entire disc.

Quote from: greynol on
and so long as there no re-reads performed regardless of the number of tracks ripped.

This is puzzling me a bit. Yes ok, admittetly chances are that detected errors mean the disc is of the same pressing and it is the errors that cause the CRC mismatch, but this still doesn't rule out the possibility of a different pressings with errors, but where the re-reads have turned out successful.

Anyway I guess a proper detection of alternative pressings will make many false "not accurate"-messages vanish.

But can we be sure that the remaining cases are indeed not accurately ripped? I think we can see "different pressings" issue as being theoretically solvable, can't we? Now what about the "remaining cases". I mean can there still be a case where the tracks were indeed accurately ripped (and everything during extraction doesn't suggest otherwise) but where there is a (partial) mismatch to the disc from the AR database? I fear it's better to migrate from "not accurate" to "cannot be verified as being accurate" anyway (good wording, btw, greynol).

Quote from: greynol on
I would propose that it say, "is [%s1], but AccurateRip returned [%s2]."

True, I shouldn't have left that one out. I wasn't thinking about the text replacing thing when I said that I liked the phrase. To be precise I like that EAC tells the user which one of the CRCs is from the rip and which one is from the online database.


@spoon: Will your method of detecting alternative pressings require or rely on multiple pressings of one disc already in the AR database? Or can it also detect a different pressing if there's only one pressing present?

The latter would be possible using the slow "re-check+offset shift" method on an offset skewed alternative pressing.

Another thing... reading between the lines in that thread at AudioSense, I take it that you plan on marking the pressings with an additional identifier in the database, an identifier/checksum that can be calculated by the AR.dll?
 

EAC 0.99pb1 and AccurateRip reporting

Reply #20 –
Quote from: Fandango on
Quote from: greynol on
and so long as there no re-reads performed regardless of the number of tracks ripped.
This is puzzling me a bit. Yes ok, admittetly chances are that detected errors mean the disc is of the same pressing and it is the errors that cause the CRC mismatch,
I'd say you determine that it could be from the same pressing based on the fact that some tracks can be verified.
Quote from: Fandango on
but this still doesn't rule out the possibility of a different pressings with errors, but where the re-reads have turned out successful.
...or didn't turn out successful.  Absolutely!

I just don't think it's fair to throw out the different pressing excuse when EAC determines there were errors (and we know EAC is quite capable of claiming none occurred even though they have), but I'm certainly being more liberal with it than dBpowerAMP since my suggestion still allows EAC to perform re-reads.  I feel like there is no other choice considering that EAC will perform re-reads at the end of the track when nothing is really wrong.  But remember, I'm only saying it may be a different pressing.

Quote from: greynol on
To be precise I like that EAC tells the user which one of the CRCs is from the rip and which one is from the online database.
Yes, and I like being able to know which is which also.  It has come in handy at times.