AccurateRip

[ghost]

I have a disc that EAC recognises as a key disc, yet Python Audio Tools refuses to acknowledge as being in the accurate rip database.

I am guessing I am doing something wrong.

I have tried setting the read offset to 0, and 594 (I believe 594 is correct). I am then running cd2track -I and ripping to flac. Do I need to change my ID3 tags? Replay gain?

Am I missing any steps? Is there a sure-fire way to make sure my read-offset is correct?

I noticed that I'm not creating a cue sheet. should I? How do I do this within python audio tools?

Thanks for your help. The tools look perfect for my needs. I just need to learn how to use them better.

[ghost]

I have tried all sorts of configurations:

[selected] output of cd-drive:

Vendor : PBDS Model : DVD+-RW DS-8W1P

Which means my offset is correct (as-is with EAC).

Current .audiotools.cfg

[Defaults] verbosity = normal

[System] cdrom_read_offset = 594 default_type = flac

[ID3] id3v2 = none id3v1 = none

[ReplayGain] add_by_default = False

eighthpence@localhost:~ $ audiotools-config --version Python Audio Tools 2.21

I have tried ripping flac, wav and wv. None seem to work. Am I doing something terribly wrong?

eighthpence@localhost:~ $ audiotools-config Default verbosity level : normal extraction arguments Type Binaries Default Quality ──── ────────── ────────────────────────────────────────────────── aiff alac au flac 8 - most compression, slowest compression speed m4a faac, faad 100 mp2 192 mp3 2 oga flac 8 - most compression, slowest compression speed ogg 3 opus 10 - best quality, slowest encode shn tta wav wv veryhigh - slowest encode/decode, best compression Format : %(track_number)2.2d - %(track_name)s.%(suffix)s Default simultaneous jobs : 1 Add ReplayGain by default : no

ID3 arguments ID3v2 tag version : no ID3v2 tags ID3v2 digit padding : not padded ("1", "2", …) ID3v1 tag version : no ID3v1 tags

CD lookup arguments Use MusicBrainz service : yes Default MusicBrainz server : musicbrainz.org Default MusicBrainz port : 80

      Use FreeDB service : yes
   Default FreeDB server : us.freedb.org
     Default FreeDB port : 80

system arguments Default CD-ROM device : /dev/cdrom CD-ROM sample read offset : 594 CD-ROM sample write offset : 0 Filesystem text encoding : UTF-8 TTY text encoding : UTF-8 Audio output : PulseAudio, ALSA, NULL

eighthpence@localhost:~ $ cdinfo Total Tracks : 10 Total Length : 56:27 (254085 frames) FreeDB disc ID : 840D390A MusicBrainz disc ID : UX1UngSvLERISZvH5TcbKuO_CXI- AccurateRip disc ID : dBAR-010-001503ba-00a9750a-840d390a.bin

Length Frames Offset── ────── ────── ────── 1 5:42 25706 151 2 5:34 25111 25856 3 4:17 19321 50966 4 5:16 23733 70286 5 5:11 23351 94018 6 5:39 25494 117368 7 9:05 40948 142861 8 4:39 20986 183808 9 6:38 29876 20479310 4:18 19417 234668

[ghost]

Just an update, I have tried this with version 2.20, 2.21 and the latest git release, all on Arch linux.

[ghost]

I've done some more playing around.

I tried building and forcing the build to not strip the binaries. It didn't help. However, running cdparanoia -w -O 594 1, and most of the tracks rip fine. The final track has issues, but it at least shows that the offset is correct. The track that didn't rip correctly was the final track. I think this is due to over-reading the lead-in and lead out. This was an issue with EAC, and I had to turn it off. However I don't know if this is a problem with python audio tools, but I don't know if this something that had been considered.

[tuffy]

I am in the process of calculating all the AccurateRip checksums across a range so that if the track is correct but offset by some small positive or negative number of PCM frames it will be detected correctly with the offset noted. But it will take me a little longer to finish, integrate with the command-line tools and add unit tests.

[ghost]

Cheers for your response. If there is anything I can send you, please say so.

Also, by way of reference, what distribution are you using for testing? As mentioned, I'm running Arch. The has meant I've had to modify the headers for one of the files (cdda.h to paranoia/cdda.h and paranoia.h to paranoia/paranoia.h). I'm guessing there are other anomalies as well in the distribution that might be causing issues.

[tuffy]

I've added offset detection to cd2track and trackverify so that if your tracks match an AccurateRip result but are just offset by some positive or negative number of samples, the offset and best confidence level will be displayed. Just plug that same offset into "audiotools-config --cdrom-read-offset" and your ripped tracks should be an exact match, if possible.

Oh, and there's no way to generate a cuesheet yet because libcdio doesn't offer a way to pull out the index points directly that I've found. cdrdao does dump .toc files which are equivalent, but I'll have to see if I can port its method to libcdio's low-level CD access routines.

I've been using the latest versions of Ubuntu Server, Mint, OS X and occasionally Fedora for testing. I haven't had to modify any header locations for them, so it's a little unusual if you have to under Arch.