abcde - inconsistent/unexpected track numbers

1

Question: How can I achieve my expected result of tracks that are numbered with sequential {DiscNumber}{TrackNumber} - Artist - Album.mp3?

Background: When using abcde to rip a set of audiobook CDs, the tracks for a given disc, for example disc 1 of a multidisc set, are numbered as below

Actual files created for Disc 1

65 - Artist - Album.mp3
66 - Artist - Album.mp3
67 - Artist - Album.mp3
68 - Artist - Album.mp3
n  - Artist - Album.mp3

Actual files created for Disc 2

 99 - Artist - Album.mp3
100 - Artist - Album.mp3
101 - Artist - Album.mp3
102 - Artist - Album.mp3
 n  - Artist - Album.mp3

Expected files for Disc 1

0101 - Artist - Album.mp3
0102 - Artist - Album.mp3
0103 - Artist - Album.mp3
0104 - Artist - Album.mp3

Expected files for Disc 2

0201 - Artist - Album.mp3
0202 - Artist - Album.mp3
0203 - Artist - Album.mp3
0204 - Artist - Album.mp3

I believe my configuration should create track names numbered like my "Expected files" above. I suspect that some online metadata (maybe from CDDB or musicbrainz), is causing them to be named with a different numeric range, even though I've explicitly named the tracks in the .cddb entry.

The command I'm using to invoke abcde: abcde -c ./.abcde.audiobook.conf -d /dev/sr0 -W 01 -p

my default abcde conf file - .abcde.conf

my override abcde conf file - .abcde.audiobook.conf

Things to note...

  1. I'm using the -W ## to prefix the filenames with disc 01, 02, ... n
  2. I'm also using -p to pad tracks, which, in my experience, does not work
  3. Given #2, I manually pad tracks 0-9 with my editor, when the CDDB entry is displayed for me.

kdford

Posted 2019-05-27T18:16:25.663

Reputation: 31

I've used abcde to rip multi-disc audiobook sets many times in the past and have never seen this behavior. I've tried removing the <TAG> action from my abcde.conf as well as the CDDB action.. nothing seems to help the issue. – kdford – 2019-05-27T18:17:47.610

Thanks for the suggestion @KamilMaciorowski. Hopefully the question is now clear. – kdford – 2019-05-27T22:46:41.457

No answers