IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Anyone who wants to write foo_accuraterip_db?, Plugin for checking any tracks
Fandango
post Aug 1 2007, 03:32
Post #1





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



Hi,

why is there no plugin that checks any selected tracks as an album using AR checksums for comparing the results with the AR database?

That would be handy, since foobar2000 would do all the conversion.

Anyone who wants to write such a plugin? Would be awesome! laugh.gif

EDIT: Thanks for moving the thread and giving it a better title. blush.gif

Some things to consider...
  • There shall be no any limitation regarding the source of the tracks used. So lossy files get decoded to PCM, just like losslessly encoded files. It doesn't hurt if the plugin is held dumb enough to not be bothered whether the source was lossy or lossless. In fact this might even be useful to verify that a false entry based on a non-CD-source has made it into the AR database, in case someone has a hunch that a specific "release" has made it into the database.

    Of course, checks on the decoded output must apply, namely that it is 16bit, 44.1kHz PCM. And maybe it's also wise to not allow internet radio streams as input for this plugin, in case it's possible to check this. Or else the user who accidentally chose such a playlist entry might wait forever for the plugin to finish.

  • Don't object: "but why any tracks? you mean you want to select some lossy files and see if they make up an album that is present in the AR database?" -- No, I don't want to do that, maybe once or twice just for the fun of it. But although it doesn't make sense to check random tracks as one album, there's also no reason why this shall not be possible.

    To make myself clearer: I think the grouping of tracks for an AR check should be implemented more or less exactly like the grouping for replaygain was done... i.e. "treat selected tracks as one album", "treat selected tracks as album(s) (using tags)".

  • There should be a log output, that can be copied and pasted or even automatically written to a file using tagz script for creating that file's name. Not just a window that says "Album was verified as being accurately ripped."/"Album couldn't be verified as being accurately ripped."

    The log output should resemble the output of the AR.dll for the time being... and maybe later, even better it could be written using user-defineable templates.
Any more ideas? Objections?

This post has been edited by Fandango: Aug 1 2007, 04:04
Go to the top of the page
+Quote Post
kanak
post Aug 1 2007, 04:12
Post #2





Group: Members
Posts: 1190
Joined: 12-January 06
From: Cambridge, MA
Member No.: 27052



I'd surely use it. Now if only someone would develop it tongue.gif
Go to the top of the page
+Quote Post
jdcarr
post Aug 24 2007, 19:53
Post #3





Group: Members
Posts: 5
Joined: 24-August 07
Member No.: 46459



QUOTE (Fandango @ Jul 31 2007, 21:32) *
Hi,

why is there no plugin that checks any selected tracks as an album using AR checksums for comparing the results with the AR database?

That would be handy, since foobar2000 would do all the conversion.

Anyone who wants to write such a plugin? Would be awesome! laugh.gif

EDIT: Thanks for moving the thread and giving it a better title. blush.gif

Some things to consider...
  • There shall be no any limitation regarding the source of the tracks used. So lossy files get decoded to PCM, just like losslessly encoded files. It doesn't hurt if the plugin is held dumb enough to not be bothered whether the source was lossy or lossless. In fact this might even be useful to verify that a false entry based on a non-CD-source has made it into the AR database, in case someone has a hunch that a specific "release" has made it into the database.

    Of course, checks on the decoded output must apply, namely that it is 16bit, 44.1kHz PCM. And maybe it's also wise to not allow internet radio streams as input for this plugin, in case it's possible to check this. Or else the user who accidentally chose such a playlist entry might wait forever for the plugin to finish.

  • Don't object: "but why any tracks? you mean you want to select some lossy files and see if they make up an album that is present in the AR database?" -- No, I don't want to do that, maybe once or twice just for the fun of it. But although it doesn't make sense to check random tracks as one album, there's also no reason why this shall not be possible.

    To make myself clearer: I think the grouping of tracks for an AR check should be implemented more or less exactly like the grouping for replaygain was done... i.e. "treat selected tracks as one album", "treat selected tracks as album(s) (using tags)".

  • There should be a log output, that can be copied and pasted or even automatically written to a file using tagz script for creating that file's name. Not just a window that says "Album was verified as being accurately ripped."/"Album couldn't be verified as being accurately ripped."

    The log output should resemble the output of the AR.dll for the time being... and maybe later, even better it could be written using user-defineable templates.
Any more ideas? Objections?


I'd sure like it too...but there's one inherent problem with it...let me know if I'm wrong, but:

Every single drive when it rips offsets the rip differently...just barely. Therefore, in order to accurately compare a rip against the accuraterip database it requires knowing the exact offset of the drive that ripped it, which makes it a little difficult, since every drive has a different offset.

That's why there's plugins for ripping programs (EAC and dbPowerAmp) and nothing else. Do I make sense?
Go to the top of the page
+Quote Post
Spirit_of_the_oc...
post Aug 24 2007, 20:32
Post #4





Group: Members
Posts: 583
Joined: 12-September 06
Member No.: 35092



Thats why you are asked in some programs to make example rips to get the right settings for your drive
Go to the top of the page
+Quote Post
odyssey
post Aug 24 2007, 21:58
Post #5





Group: Members
Posts: 2296
Joined: 18-May 03
From: Denmark
Member No.: 6695



It would be great for such plugin, but I don't see any use for it in regard to lossy files - AT ALL! In fact I don't think that this plugin should be able to submit any data.

If such plugin is developed, it should check if %DISCID% is set on the files, and check them upon this particular disc. If it's not found, you would only be able to verify AR data if you select an entire album and AR could calculate the DISCID from this.

A little bonus feature I hope to be possible is the check for offset correction. I'm not sure if this is possible with *every* disc, but according to AR it should be, since any discs could be used as configuration disc.


--------------------
Can't wait for a HD-AAC encoder :P
Go to the top of the page
+Quote Post
NormanPCN
post Aug 24 2007, 22:39
Post #6





Group: Members
Posts: 29
Joined: 16-February 06
From: Thousand Oaks, CA
Member No.: 27788



QUOTE (jdcarr @ Aug 24 2007, 11:53) *
I'd sure like it too...but there's one inherent problem with it...let me know if I'm wrong, but:

Every single drive when it rips offsets the rip differently...just barely. Therefore, in order to accurately compare a rip against the accuraterip database it requires knowing the exact offset of the drive that ripped it, which makes it a little difficult, since every drive has a different offset.


Accuraterip requires you calibrate with a known key disc which has a known offset and therefore you can properly determine the drive offset. I use accuraterip when doing my 277 CDs with dbPowerAmp. Very nice feature since if the first pass of my rip agreed with the database then the ripper did not bother with secure mode. Makes for very fast rips excpt for scratched tracks or CDs not in the DB. A CD can be in the database but you might have a CD with a different production run(pressing) so in that case you still go secure.

I am out for looking at doing something like this. I would not touch C++ with a ten foot pole. Modula-2 is my game.

This post has been edited by NormanPCN: Aug 24 2007, 22:40
Go to the top of the page
+Quote Post
Jose Hidalgo
post Jan 11 2008, 19:17
Post #7





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



Hi everyone,

Please count me in : such component would be a great idea if properly developed. smile.gif

QUOTE (Fandango @ Jan 11 2008, 18:52) *
A fb2k component [...] could access the track's PCM audio provided by the converter directly, no need to worry about codecs or cue sheets or tags for the writer of such a component. Ok, maybe it would be a good idea to store the AR CRC in the tag, so this time consuming operation of calculating the CRC is only necessary once... cool.gif I don't know if writing the confidence to the tag is a good idea, since this number will change (increase) over time and therefor becomes out-of-date.

I think the component should be able to calculate the CRC of each file and store them in the tag (the file CRC, not the AR CRC of course ! what would be the use in storing the AR CRC if it's not the same as the file CRC ? tongue.gif ).

I also think that writing the confidence to the tag *would* be a good idea, since it can help distinguish very reliable rips (with high confidence scores) from less reliable ones (with 1-2 confidence scores for example). So one could choose to sort the files by the "AR confidence" field, select the ones with the lower scores, then re-check them over time to see if their confidence improves or not. If it doesn't, then either the CD is a very rare one, or then it could be a good idea to re-rip it and see what happens.

QUOTE (odyssey @ Aug 24 2007, 21:58) *
If such plugin is developed, it should check if %DISCID% is set on the files, and check them upon this particular disc. If it's not found, you would only be able to verify AR data if you select an entire album and AR could calculate the DISCID from this.

I agree with you (but lossless collections very often are made of entire albums, so this shouldn't be a big problem). And once we have calculated the DISCID, why not store it too in a %discid% tag field for all the album tracks ? It can't be a bad thing, can it ?

QUOTE (odyssey @ Aug 24 2007, 21:58) *
A little bonus feature I hope to be possible is the check for offset correction. I'm not sure if this is possible with *every* disc, but according to AR it should be, since any discs could be used as configuration disc.

Yes, why not. But the main thing for me would be to NOT use silence samples for CRC calculations. That should solve a part of the offset problems IMHO, since most tracks begin and end with a part of silence. Am I wrong ?

This post has been edited by Jose Hidalgo: Jan 11 2008, 19:21
Go to the top of the page
+Quote Post
Fandango
post Jan 11 2008, 19:24
Post #8





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



A wrong offset correction is always an issue when doing an AR check on a rip in retrospect.

The AR-approved-and-enabled rippers make use of AR's calibration, whereas this was not the case with the rips you want to check retrospectively. Although you may have been so wise to manually set the read offset correction in EAC anyway.

But in those cases where you didn't use an AR-enabled ripper or a manually configured EAC, the most important piece of information is taken from the EAC log here. It gives us two important clues about the correctness of the offset correction: the offset correction applied on the audio itself and the drive's model. For other rippers than EAC, knowing the drive's model will do, since they usually rip without offset correction anyway, and the rare case that can happen with a misconfigured EAC where you have to "correct the incorrect read offset correction" should never happen here.

In combination with the drive database that can be found at the AccurateRip homepage, a wrong offset correction shouldn't be a problem anymore in theory. The only challenge would be to apply the right correction to your rip. You can do this manually with a tool like CUE Tools, but when you want to batch process ten thousands of tracks with fb2k, then this simply doesn't work.

So some kind of EAC log processing for the lossless rips with wrong offsets would be a nice extra feature. I say extra feature, because it's really your fault if you hadn't set the offset correction in EAC. Of course, this does not apply when you didn't use EAC... wink.gif

So a simpler solution which is maybe sufficient for most cases is to be able to set an offset correction in the preferences page of this component. Assuming that most of your rips were made with the same drive, this should do.

@Jose Hidalgo:
QUOTE (Jose Hidalgo @ Jan 11 2008, 19:17) *
(the file CRC, not the AR CRC of course ! what would be the use in storing the AR CRC if it's not the same as the file CRC ? tongue.gif )

I know what you mean, but let's stick to the convention that when talking about "AR CRC" it does not explicitely mean the CRC stored in the database. Because AccurateRips way of creating a CRC from the track is different from a "normal" CRC of the tracks' audio. If you would CRC the raw PCM of a track (like EAC does it) and then do a CRC check AR-style both results will differ always. Therefor I am using the term "AR CRC" no matter if it's the AR CRC of the local file or the AR CRC in the database. wink.gif

QUOTE (Jose Hidalgo @ Jan 11 2008, 19:17) *
QUOTE (odyssey @ Aug 24 2007, 21:58) *

A little bonus feature I hope to be possible is the check for offset correction. I'm not sure if this is possible with *every* disc, but according to AR it should be, since any discs could be used as configuration disc.

Yes, why not. But the main thing for me would be to NOT use silence samples for CRC calculations. That should solve a part of the offset problems IMHO, since most tracks begin and end with a part of silence. Am I wrong ?
AccurateRip's way of calculating the CRC is quite different from the way EAC does it, throwing out silent samples is not an option, and would give negative AR results always. And honestly I don't see how cutting of silent samples has anything to do with offset correction. You want all your tracks to be correct, not just those with silence at the beginning and the end, and besides silent samples are used for AR calculation, too. So this will never work.

What's really needed for rips without offset correction is to get to know the read offset of the drive used for ripping. And that's no problem, right? Because you ripped the CDs yourself, right? dry.gif

This post has been edited by Fandango: Jan 11 2008, 19:50
Go to the top of the page
+Quote Post
odyssey
post Jan 11 2008, 20:16
Post #9





Group: Members
Posts: 2296
Joined: 18-May 03
From: Denmark
Member No.: 6695



QUOTE (Fandango @ Jan 11 2008, 19:24) *
What's really needed for rips without offset correction is to get to know the read offset of the drive used for ripping. And that's no problem, right? Because you ripped the CDs yourself, right? dry.gif

Yes I did - With several different drives, a few of them are already thrown away and I don't have much logs. I noticed after a while that I didn't use offset correction (that was before I used AccurateRip - It wasn't very widespread back then)


--------------------
Can't wait for a HD-AAC encoder :P
Go to the top of the page
+Quote Post
Jose Hidalgo
post Jan 11 2008, 22:07
Post #10





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



+1 : Fandango, I can assure that I have ripped ALL of my CDs (and I mean more than 1.000 legally-bought CDs) myself, with EAC and Accuraterip (who calculated my drive's offset automatically based on 3 different CDs).

However, I agree with odyssey : I have ripped some of my CDs at a friend's appartment who as a different drive with a different offset. Besides, in the near future, I may also want to change my drive for another model with a different offset.

And of course once you mix up all those ripped CDs in the same hard drive, you don't necessarily remember what CDs have been ripped with what drive. Of course I have most of the EAC logs, but again, having a look manually at more than 1.000 logs doesn't look like a good solution to me...

As for the AR logs, I have very few of them. Why ? Because with EAC 0.95b4 a year ago, it was a bit of a pain to manually copy/paste them in individual files. So I did it only when they indicated no confidence (CD not in database, or incorrect results).

Voilą. wink.gif
Go to the top of the page
+Quote Post
Fandango
post Jan 12 2008, 00:09
Post #11





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



That's what I think most people will have. Either the drive offset was corrected be it manually or with the help of AR, or it wasn't corrected at all, but most of the rips are done with the same drive.

So for offset corrected rips that have not been AR-checked while ripping there's no problem at all.

And for those rips that have no been offset corrected, a single setting for this component to use a temporary offset correction would also suffice.

In cases where the user who didn't use to care about offset correcting bought a new drive and he still can sort the rips by date and use a different offset for the tests on each batch of rips.

As a deluxe solution I was thinking about an EAC log parser that in combination with a drive offset database can do this on a per rip basis, but that probably is overkill.
Go to the top of the page
+Quote Post
Jose Hidalgo
post Jan 12 2008, 02:38
Post #12





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



Well, all this stuff looks promising. Now all we've got to do is find a dev willing to do it. Guys ?... biggrin.gif
Go to the top of the page
+Quote Post
Fandango
post Jan 12 2008, 16:09
Post #13





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



QUOTE (Jose Hidalgo @ Jan 12 2008, 02:38) *
Well, all this stuff looks promising. Now all we've got to do is find a dev willing to do it. Guys ?... biggrin.gif

...ah yes, back to problem #1. biggrin.gif
Go to the top of the page
+Quote Post
ssjkakaroto
post Jan 27 2008, 16:05
Post #14





Group: Members
Posts: 203
Joined: 22-May 02
Member No.: 2096



It would already be really useful if AR was integrated with the ripping function of fb2k.


--------------------
Allegari nihil et allegatum non probare, paria sunt.
Go to the top of the page
+Quote Post
Fandango
post Feb 3 2008, 21:38
Post #15





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



QUOTE (ssjkakaroto @ Jan 27 2008, 16:05) *
It would already be really useful if AR was integrated with the ripping function of fb2k.

True. It would be a real bonus to the fb2k ripper.
Go to the top of the page
+Quote Post
2tec
post Apr 13 2008, 15:14
Post #16





Group: Members
Posts: 334
Joined: 29-February 08
From: Alberta
Member No.: 51676



QUOTE (Fandango @ Jul 31 2007, 19:32) *
why is there no plugin that checks any selected tracks as an album using AR checksums for comparing the results with the AR database?

huh.gif I'm sorry but just exactly how do you mean "check"? Are you hoping to verify that the audio data is unchanged?

If so, then how about http://wiki.etree.org/index.php?page=FlacFingerprint


--------------------
Censorship reflects society's lack of confidence~Potter Stewart
Go to the top of the page
+Quote Post
gausome
post Apr 21 2008, 20:25
Post #17





Group: Members
Posts: 4
Joined: 21-April 08
Member No.: 52964



QUOTE (2tec @ Apr 13 2008, 08:14) *
QUOTE (Fandango @ Jul 31 2007, 19:32) *

why is there no plugin that checks any selected tracks as an album using AR checksums for comparing the results with the AR database?

huh.gif I'm sorry but just exactly how do you mean "check"? Are you hoping to verify that the audio data is unchanged?

If so, then how about http://wiki.etree.org/index.php?page=FlacFingerprint

That is very interesting, it is exactly what is needed in to perform a check of the audio data. It seems like the last step would be to combine this feature with something like the AccurateRip database, so that any "Flac Fingerprint" can be compared with other users and given a confidence rating, which would let you determine if any flaws exist in the audio.

This post has been edited by gausome: Apr 21 2008, 20:27
Go to the top of the page
+Quote Post
Borisz
post Apr 25 2008, 12:34
Post #18





Group: Members
Posts: 381
Joined: 27-September 03
Member No.: 9041



I would be perfectly content with just a scanner, that can do nothing else but telling me if my files are accurate (and to what confidence & the crc).

It would be nice if it would work for multiple album inputs, tough (the same way the replaygain scanner does). That way I could verify a lot of my flac rips in one pass - right now the only way i can verify them is to burn them on disc, then rerip in eac. Very painful process.


--------------------
http://evilboris.sonic-cult.net/346/
Sega Saturn, Shiro!
Go to the top of the page
+Quote Post
unfortunateson
post Jun 11 2008, 18:59
Post #19





Group: Members
Posts: 294
Joined: 28-July 04
Member No.: 15838



hope to see this come to fruition someday.
Go to the top of the page
+Quote Post
Parsi
post Jul 18 2008, 18:06
Post #20





Group: Members
Posts: 44
Joined: 8-July 08
Member No.: 55516



I just wanted to open up a new thread about this.
I wish I was a programmmer.

However I would really appreciate this. although a working version of arflac.exe would do fine for me as well - if it would exist smile.gif


--------------------
All tracks accurately ripped

End of status report
Go to the top of the page
+Quote Post
odyssey
post Jul 18 2008, 19:44
Post #21





Group: Members
Posts: 2296
Joined: 18-May 03
From: Denmark
Member No.: 6695



QUOTE (Parsi @ Jul 18 2008, 19:06) *
However I would really appreciate this. although a working version of arflac.exe would do fine for me as well - if it would exist smile.gif
arcue.exe already exists. Also flac.exe and shntool.exe exists if you need to decode and/or combine seperate files. Only I became aware of a spoiler today that makes it impossible for me to use it, because it doesn't take pregap (INDEX 00) in TRACK 01 into account, so all my albums with this will fail when I try.

I really hope some programmer would pickup this, and take offset into account. I would myself, but I still have no C++ experience sad.gif


--------------------
Can't wait for a HD-AAC encoder :P
Go to the top of the page
+Quote Post
XPEHOPE3
post Jul 28 2008, 06:56
Post #22





Group: Members
Posts: 4
Joined: 9-July 08
Member No.: 55546



Such an utility exists.
It looks like this:

It's set up via foobar converter like this:

It can be downloaded here. Since that site doesn't allow direct links you have to click here:

I'm not the author. The author doesn't know yet about my post here - he is at vacations right now.
The utility is in the alpha state, it's the first test version, please beware.
Go to the top of the page
+Quote Post
odyssey
post Jul 28 2008, 08:33
Post #23





Group: Members
Posts: 2296
Joined: 18-May 03
From: Denmark
Member No.: 6695



QUOTE (XPEHOPE3 @ Jul 28 2008, 07:56) *
Such an utility exists.

But does it write the results in tags or even work with multiple albums at the same time ??

QUOTE (gausome @ Apr 21 2008, 21:25) *
QUOTE (2tec @ Apr 13 2008, 08:14) *

QUOTE (Fandango @ Jul 31 2007, 19:32) *

why is there no plugin that checks any selected tracks as an album using AR checksums for comparing the results with the AR database?

huh.gif I'm sorry but just exactly how do you mean "check"? Are you hoping to verify that the audio data is unchanged?

If so, then how about http://wiki.etree.org/index.php?page=FlacFingerprint

That is very interesting, it is exactly what is needed in to perform a check of the audio data. It seems like the last step would be to combine this feature with something like the AccurateRip database, so that any "Flac Fingerprint" can be compared with other users and given a confidence rating, which would let you determine if any flaws exist in the audio.

I don't think so. The internal stored md5 seem to be a checksum of the compressed file without headers. This means, different md5 sums for different flac versions or even different compression levels.

Calling it a "fingerprint" is a little way off IMHO.

Edit: Confusing article. Their "fingerprinting" method seems to me to be just a checksum of the decoded filedata. That's no different from the data stored in AR.

For those who don't know there's a small util called "Tripleflac" that does this on flac-files and even shows the offset! Still it would be great to have a "point 'n click" component that eases this in foobar, but for now it pretty well accomplishes my task.

This post has been edited by odyssey: Jul 28 2008, 08:38


--------------------
Can't wait for a HD-AAC encoder :P
Go to the top of the page
+Quote Post
XPEHOPE3
post Jul 28 2008, 09:16
Post #24





Group: Members
Posts: 4
Joined: 9-July 08
Member No.: 55546



QUOTE
But does it write the results in tags or even work with multiple albums at the same time ??
It is first test version) you're demanding too much from it. Multiple albums support is planned AFAIR. Results would be saved most probably to a text file only.
Go to the top of the page
+Quote Post
twostar
post Jul 28 2008, 12:09
Post #25





Group: Members
Posts: 487
Joined: 5-August 02
From: Manila
Member No.: 2939



Fooaccrip works for me. I tested with a cd ripped with EAC burst mode. EAC reports that all but 2 tracks were ripped accurately. Fooaccrip reports the same.
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 26th December 2014 - 04:35