[Enhancement] Sort by "CD From Filename" and read CD id3 tag #80

Closed
opened 2026-04-24 22:57:52 +02:00 by adam · 10 comments
Owner

Originally created by @juriroemer on GitHub (Oct 27, 2021).

Can we have the track manager auto sorting (see #128) for the "CD From Filename" column aswell? :) That way it would be possible to get the right order for books where all CDs start at 1 by first sorting by Track ID, then sorting by CD.

Also I think the "CD From Filename" is only populated by parsing the track name, if I'm not mistaken? Having it also look at the corresponding id3 tag and the folder name would be nice.

Originally created by @juriroemer on GitHub (Oct 27, 2021). Can we have the track manager auto sorting (see #128) for the "CD From Filename" column aswell? :) That way it would be possible to get the right order for books where all CDs start at 1 by first sorting by Track ID, then sorting by CD. Also I think the "CD From Filename" is only populated by parsing the track name, if I'm not mistaken? Having it also look at the corresponding id3 tag and the folder name would be nice.
adam added the enhancement label 2026-04-24 22:57:52 +02:00
adam closed this issue 2026-04-24 22:57:53 +02:00
Author
Owner

@advplyr commented on GitHub (Oct 29, 2021):

The CD is only parsed from the filename because I didn't see any ID3 tags for the CD #. Do you know which ID3 tag your audio files use for CD #?
In my audiobooks the CD is usually in the name of the album or title meta tag.

@advplyr commented on GitHub (Oct 29, 2021): The CD is only parsed from the filename because I didn't see any ID3 tags for the CD #. Do you know which ID3 tag your audio files use for CD #? In my audiobooks the CD is usually in the name of the album or title meta tag.
Author
Owner

@seanap commented on GitHub (Nov 9, 2021):

I use DISCNUMBER (TPOS) for CD#
image

@seanap commented on GitHub (Nov 9, 2021): I use DISCNUMBER (TPOS) for CD# ![image](https://user-images.githubusercontent.com/17012946/140861844-3167c702-4e8d-4a9c-90e2-8018c9ab714a.png)
Author
Owner

@juriroemer commented on GitHub (Nov 9, 2021):

Yes I'm not 100% sure which would be the right tag, but I've seen id3 tag editors having a CD# column...

@juriroemer commented on GitHub (Nov 9, 2021): Yes I'm not 100% sure which would be the right tag, but I've seen id3 tag editors having a CD# column...
Author
Owner

@zombiehoffa commented on GitHub (Nov 16, 2021):

While not a permanent solution, if you just want to get it working music brainz picard https://picard.musicbrainz.org/ has decent id3 tag editing abilities (including generating id3 tags from file names). I use it to clean up my audiobooks just enough for readarr to recognize it and take it the rest of the way then mount the readarr audiobook dir in my audiobookshelf docker read only so audiobookshelf doesn't mess up readarr.

@zombiehoffa commented on GitHub (Nov 16, 2021): While not a permanent solution, if you just want to get it working music brainz picard https://picard.musicbrainz.org/ has decent id3 tag editing abilities (including generating id3 tags from file names). I use it to clean up my audiobooks just enough for readarr to recognize it and take it the rest of the way then mount the readarr audiobook dir in my audiobookshelf docker read only so audiobookshelf doesn't mess up readarr.
Author
Owner

@KindOfOK commented on GitHub (Jan 3, 2022):

Yeah, I'm also having problems with how tracks are parsed upon addition to the library.

My filenames are in the format of "disc-track - title.ext" (e.g., 1-03 - Chapter 1c.mp3). Specifically, while the filenames do have leading zeroes for the track number, they (unfortunately!) do not have leading zeros for the disc number. Audiobookshelf appears to not be able to sort per this convention. In fact, the "CD from Filename" column is entirely blank. This results in all the tracks being out of order, beginning with the second disc being presented first - see screenshot (red).

image

Also, on a separate but related note, in the settings, I have "scanner prefer audio metadata" toggled on - in the below screenshot, you can see that the program appears to be parsing the track number from both sources: this metadata and also the filename (green). You will note that the output between these methods does not match, which suggests that the naming convention I've used for my filenames may be causing issue. In fact, if you look closely, multiple duplicate track numbers are presented, which to me, suggests that the program is interpreting the leading number of the filename as the track number, not the disc number as my naming convention follows.

When you combine these above factors, it causes problems: the disc number in the filename isn't be "correctly" recognized and the track number is not agreed upon. The result is that 'duplicate track number "[number]"' is generated (blue) and Audiobookshelf understandably doesn't know how to reconcile this.

image

I would argue that the resolution to the issue is to rely 100% on the metadata. If I'm understanding the conversation above, @advplyr , you're suggesting that there isn't clarity on what the ID3 tag(s) should be. It's my experience that the below tags are pretty universal and would be what I recommend. Regardless, can we pick some tag for track, total tracks, disc, and total discs, and just go with it, indicating those tags in the Documentation page on the website? As you've already indicated in the table on that Documentation, perhaps even consider a primary and a secondary (fallback) option for these tags?

image

If, however, ID3 tags/metadata is not to be relied upon, can the Documentation be updated to add what the expected filename naming convention is? Perhaps, as you've already done in the settings, maybe the answer is to provide both options?

At this point, I'm only an ideas man. I don't have any of the requisite programming skills to contribute there. However, I am interested in anyone's thoughts, as I have to imagine that this is a common scenario.

@KindOfOK commented on GitHub (Jan 3, 2022): Yeah, I'm also having problems with how tracks are parsed upon addition to the library. My filenames are in the format of "disc-track - title.ext" (e.g., 1-03 - Chapter 1c.mp3). Specifically, while the filenames do have leading zeroes for the track number, they (unfortunately!) do _not_ have leading zeros for the disc number. Audiobookshelf appears to not be able to sort per this convention. In fact, the "CD from Filename" column is entirely blank. This results in all the tracks being out of order, beginning with the second disc being presented first - see screenshot (red). ![image](https://user-images.githubusercontent.com/15337331/147896441-2399bffa-c8e5-478a-b194-a046457212d4.png) Also, on a separate but related note, in the settings, I have "scanner prefer audio metadata" toggled on - in the below screenshot, you can see that the program appears to be parsing the track number from both sources: this metadata and also the filename (green). You will note that the output between these methods does not match, which suggests that the naming convention I've used for my filenames may be causing issue. In fact, if you look closely, multiple duplicate track numbers are presented, which to me, suggests that the program is interpreting the leading number of the filename as the track number, not the disc number as my naming convention follows. When you combine these above factors, it causes problems: the disc number in the filename isn't be "correctly" recognized and the track number is not agreed upon. The result is that 'duplicate track number "[number]"' is generated (blue) and Audiobookshelf understandably doesn't know how to reconcile this. ![image](https://user-images.githubusercontent.com/15337331/147896955-10bc562b-0944-4256-aa21-3c0ad061e0b0.png) I would argue that the resolution to the issue is to rely 100% on the metadata. If I'm understanding the conversation above, @advplyr , you're suggesting that there isn't clarity on what the ID3 tag(s) should be. It's my experience that the below tags are pretty universal and would be what I recommend. Regardless, can we pick _some_ tag for _track_, _total tracks_, _disc_, and _total discs_, and just go with it, indicating those tags in the [Documentation page](https://www.audiobookshelf.org/docs#metadata) on the website? As you've already indicated in the table on that Documentation, perhaps even consider a primary and a secondary (fallback) option for these tags? ![image](https://user-images.githubusercontent.com/15337331/147897323-83b8042d-1471-4066-a3d7-72c3dff90a4d.png) If, however, ID3 tags/metadata is not to be relied upon, can the [Documentation](https://www.audiobookshelf.org/docs) be updated to add what the expected filename naming convention is? Perhaps, as you've already done in the settings, maybe the answer is to provide _both_ options? At this point, I'm only an ideas man. I don't have any of the requisite programming skills to contribute there. However, I am interested in anyone's thoughts, as I have to imagine that this is a common scenario.
Author
Owner

@MidnightSnowleopard commented on GitHub (Jan 3, 2022):

I was grappling with this myself. I've checked the code and it literally check for something along the line of "disc xx" for file name based checking. It also seems to be case sensitive in my testing with "Disc 1" not being detected but "disc 1" being detected. Once it conforms to this exact format it will detect.

Unfortunately this doesn't really fix the issue as it fills out the "CD from Filename" column correctly with information on it and then still labels all tracks with the same number as conflicting even with different disc numbers assigned to each.

advplyr has already stated in a referenced issue that this is something that intended to be supported in the future.

Originally posted by @advplyr in https://github.com/advplyr/audiobookshelf/issues/127#issuecomment-996335297

@MidnightSnowleopard commented on GitHub (Jan 3, 2022): I was grappling with this myself. I've checked the code and it literally check for something along the line of "disc xx" for file name based checking. It also seems to be case sensitive in my testing with "Disc 1" not being detected but "disc 1" being detected. Once it conforms to this exact format it will detect. Unfortunately this doesn't really fix the issue as it fills out the "CD from Filename" column correctly with information on it and then still labels all tracks with the same number as conflicting even with different disc numbers assigned to each. advplyr has already stated in a referenced issue that this is something that intended to be supported in the future. _Originally posted by @advplyr in https://github.com/advplyr/audiobookshelf/issues/127#issuecomment-996335297_
Author
Owner

@KindOfOK commented on GitHub (Jan 7, 2022):

Ah - got it. I'm sorry I missed that posting - thanks for pointing that out, @MidnightSnowleopard !

@advplyr , I wish I could help - I'd be happy to beta test anything, but probably can't do much else! Good luck, and I look forward to any resolution!

@KindOfOK commented on GitHub (Jan 7, 2022): Ah - got it. I'm sorry I missed that posting - thanks for pointing that out, @MidnightSnowleopard ! @advplyr , I wish I could help - I'd be happy to beta test anything, but probably can't do much else! Good luck, and I look forward to any resolution!
Author
Owner

@advplyr commented on GitHub (Jan 9, 2022):

Is your naming convention for the audio files standard? I'm not sure how the scanner would determine in your example which number is the CD and which number is the track.

Right now the CD# is parsed from the filename only if it is preceded by "cd" or "disc" case-insensitive. The CD# isn't actually used for anything yet.

I'm not sure how to handle CD #. I'm thinking it will only be useful for ordering the tracks. I have a few audiobooks with CD and the scanner doesn't do well with them because of the duplicate track #'s. Then the scanner will set an internal track number ignoring the CD's.

I'm going to add the ID3 metadata parse for CD and see about properly sorting audiobooks with CD's.

@advplyr commented on GitHub (Jan 9, 2022): Is your naming convention for the audio files standard? I'm not sure how the scanner would determine in your example which number is the CD and which number is the track. Right now the CD# is parsed from the filename only if it is preceded by "cd" or "disc" case-insensitive. The CD# isn't actually used for anything yet. I'm not sure how to handle CD #. I'm thinking it will only be useful for ordering the tracks. I have a few audiobooks with CD and the scanner doesn't do well with them because of the duplicate track #'s. Then the scanner will set an internal track number ignoring the CD's. I'm going to add the ID3 metadata parse for CD and see about properly sorting audiobooks with CD's.
Author
Owner

@advplyr commented on GitHub (Jan 10, 2022):

Just released v1.6.56 that also pulls the disc number from metadata.

For new audiobook scans I added a new method for ordering the tracks that takes into account the disc number. It tries to use whichever value is more accurate, the filename or metadata number.
The meta tag it looks for is discnumber or disc or disk or tpos

@advplyr commented on GitHub (Jan 10, 2022): Just released `v1.6.56` that also pulls the disc number from metadata. For new audiobook scans I added a new method for ordering the tracks that takes into account the disc number. It tries to use whichever value is more accurate, the filename or metadata number. The meta tag it looks for is `discnumber` or `disc` or `disk` or `tpos`
Author
Owner

@advplyr commented on GitHub (Jan 10, 2022):

That version had issues, updated to v1.6.57 and added docs for how audio tracks are ordered: https://www.audiobookshelf.org/docs#tracks

@advplyr commented on GitHub (Jan 10, 2022): That version had issues, updated to `v1.6.57` and added docs for how audio tracks are ordered: https://www.audiobookshelf.org/docs#tracks
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#80