Ar2 will only be of any use when the database becomes populated with AR2 data, so even if it was released tomorrow it would take 6-12 months for AR data to fill the db.
I understand that. However, I want to help populate it AND I hope to be able to later check my files against AR2 after it is populated, and this may only be possible if ripped with AR2 enabled and an AR2id is assigned.
Will the release of AR2 solve the different pressing problem on AR1 entries, or only for new entries in AR2? There has been some hint/hope that AR1 would be able to verify across pressings, right?
you are surely aware that there are now independent offset-correction software available for retroactive AccurateRip verification. Not that I find any good documentation on TripleFlac and fooAccRip, but at least the CueTools developer is active at Hydrogenaudio, and I pointed out to him dBpoweramp's choice of tagging for AccurateRipDiscId and result, see http://www.hydrogenaudio.org/forums/...ic=66233&st=50 and his response.
Given that these applications are starting to come around, and assuming that AccurateRip2 will be able to identify offset-only-different pressings, I think that now might be the appropriate time to discuss a choice of design of new tags. You may or may not consider the design of AR2 as closed, and you may or may not consider the design of the tag reporting as closed too, and whether it is still open for discussion you may want to rather involve Hydrogenaudio with its bigger braintrust.
But to just state an example, an AccurateRip2Result tag could look like:
AccurateRip2Result=AccurateRip2: Accurate (confidence 10) [BFD8DBAE] @ +99, Accurate (confidence 8) [xxxxxxxx] @ -14, ...
where the "+99" and "-14" are changes in offset compared to the drive's standard offset. Now there is an issue: what order should the accuracies be stated in? IMHO there is a difference between a "disc offset" which makes pressing1 = pressing2, and "track offsets" which makes some but not all tracks match (in which case there either is something wrong, or some pressing has extra zeroes somewhere). Maybe you even want (1) the +0 result, then (2) the best discoffset result, then (3) the best trackoffset result?
Just in case it is still open for discussion, a request: I wish AccurateRip2 be immune to the presence of data tracks too, as some pressings do include data tracks absent in others.
An idea, by the way: As dBpoweramp users have AccurateRip tags in their lossless files, a new version of dBpoweramp might include an "AccurateRip wants your old files" option -- let user point you to music library folder, scan for losslesses, calculate checksum, submit to AccurateRip2. As time goes by and AR2 is populated, include an option to update AccurateRip tags.
Edit: I guess EAC tags could be recognizable too.
Last edited by Porcus; October 20, 2008, 09:55 AM.
Comment