Audiobookshelf and using comma to seperate genres (and maybe other list metadata?)

[DaeDroug]

Describe the bug
So not strictly a bug but an incompatibility with Audiobookshelf, I've raised an issue on their end as well.
Basically the Genre metadata in the files being downloaded with libation are currently causing Audiobookshelf to list them as one giant genre rather than seperate genres. I'm not sure if this on your side or Audible's side but the simple fix would seem to be to use ; rather than , to seperate genres especially since some audible genre's include apostrophes.

To Reproduce
Steps to reproduce the behavior:

1. download audiobook with libation
2. import to audiobookshelf
3. check the genre listing

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Platform

Synology Docker

[rmcrackan]

I feel like this is an enhancement and not a bug. If you feel strongly otherwise though I can change it back.

[DaeDroug]

that's fine with me o7

[CLHatch]

I was just reading a discussion about this on the ABS repo here... advplyr/audiobookshelf#3127

Don't know how true this is, but it's mentioned that Libation is about the only app that uses commas between genres. The issue people are having is that Audible has a few genres with , in them, so if you then use , to separate them, it makes it hard to parse. I'm not sure if the "standard" is to use ; or /, if there even is one.

[rmcrackan]

If there's a standard I can easily change. I chose that because it just felt natural. I'm in no way married to the comma.

[DaeDroug]

I don't know much programming but in the ones I do know i think this would be handled one of 2 ways. Either "genre1", "genre2" or genre1; genre2
I think the latter would work as is with audiobookshelf (if you copy paste genre1; genre2 in the genre field it automatically separates it into separate genres).
The former would be workable with commas being used in the genres but would likely take extra work to support on their end.

[rmcrackan]

This actually comes directly from audible; I don't touch 'genre'.

I looked through my code and the code of the audio library I use and nowhere is genre manipulated. Evidently it wasn't me after all. I was thinking of "Categories."

[CLHatch]

This actually comes directly from audible; I don't touch 'genre'.

I looked through my code and the code of the audio library I use and nowhere is genre manipulated. Evidently it wasn't me after all. I was thinking of "Categories."

Ah. I was assuming that it came from Audible in an array in a json format, and you concatenated them as a list, using , as a separator.

Edit:
Hmm, I'm confused now. Just realized that is how it's received (at least, in the downloaded .json file). Isn't "category" the same as "genre" here, just two names for the same thing?

  "category_ladders": [
    {
      "ladder": [
        {
          "id": "18580606011",
          "name": "Science Fiction & Fantasy"
        },
        {
          "id": "18580628011",
          "name": "Science Fiction"
        },
        {
          "id": "18580645011",
          "name": "Space Opera"
        }
      ],
      "root": "Genres"
    }
  ],

[CLHatch]

Doing some Googling, I've been reading that the "standard" ways of doing multiple genres is to use either ;, /, or // (bit of confusion on that last one, because I've also read that some apps that use // actually convert that to be a nul).

Edit:
That would make that category ladder I showed embedded as one of these options:
Science Fiction & Fantasy;Science Fiction;Space Opera (or possibly ; , don't know?)
Science Fiction & Fantasy/Science Fiction/Space Opera
Science Fiction & Fantasy//Science Fiction//Space Opera
Science Fiction & FantasyNULScience FictionNULSpace Opera (where NUL is a hex 00).

[rmcrackan]

If it's embedded in the file (ie: id3 metadata tags) then it just means that audible populates these in the audio file, encrypts the file, and they're still there when I decrypt. What appears in that json file is not guaranteed to match the file. They come via 2 separate routes.

Audible does some wonky things like this. If I recall, there's chapter info embedded in the file itself, but the official audible app actually downloads a separate bit of data via their api (like with that json above) and uses that instead. Michael and I got to discover this when a user had different results when playing the file as a single file (chapter info was embedded) vs splitting files by chapter (Libation used the api to get chapter divisions and info.

[CLHatch]

If it's embedded in the file (ie: id3 metadata tags) then it just means that audible populates these in the audio file, encrypts the file, and they're still there when I decrypt. What appears in that json file is not guaranteed to match the file. They come via 2 separate routes.

Audible does some wonky things like this. If I recall, there's chapter info embedded in the file itself, but the official audible app actually downloads a separate bit of data via their api (like with that json above) and uses that instead. Michael and I got to discover this when a user had different results when playing the file as a single file (chapter info was embedded) vs splitting files by chapter (Libation used the api to get chapter divisions and info.

Oh, lovely. :-D Gotta love the "standards" that Audible is using. Maybe we should be using the API to download the categories/genres as well?

[rmcrackan]

Maybe we should be using the API to download the categories/genres as well?

Perhaps. There's no easy answer. Some people feel strongly about having it as correct as possible, some feel strongly about it being as untouched as possible by other software, some think there should be more and more settings to let them personalize endlessly, and some think there should be fewer settings and it should be simple.

"You can't please all the people all the time. And last night, all those people were at my show.

• Mitch Hedberg

[CLHatch]

Maybe we should be using the API to download the categories/genres as well?

Perhaps. There's no easy answer. Some people feel strongly about having it as correct as possible, some feel strongly about it being as untouched as possible by other software, some think there should be more and more settings to let them personalize endlessly, and some think there should be fewer settings and it should be simple.

"You can't please all the people all the time. And last night, all those people were at my show.

• Mitch Hedberg

Yeah, was thinking about that. Question is, which is more "correct" in this case. I'm guessing that the categories through the API might be updated more often than the media files, so those might end up being more "correct"? Was thinking that because they can fix those without having to redo the media file itself.