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

from python-audio-tools.

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

from python-audio-tools.

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.

from python-audio-tools.

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.

from python-audio-tools.

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.

from python-audio-tools.

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.

from python-audio-tools.