[GH-ISSUE #403] Discussion: Compilation Albums #290

New issue

Closed

opened 2026-02-26 02:32:42 +03:00 by kerem · 36 comments

kerem commented 2026-02-26 02:32:42 +03:00

Owner

Copy link

Originally created by @BernardGoldberger on GitHub (Aug 11, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/403

I might be in over my head, but I think the solution for compilation has been somewhat over complicated.

[please correct me if I'm wrong]

Original implementation

We record artist info at the album level, which presented an issue when it came to compilation albums as it would separate the song into multiple albums, this was caused by albums being depended on Artists artist->album->song

Current solution

We always ignore song artist and simply store that at the album level We use the albumArtist tag to determine if a song is part of compilation album.

If it is part of a compilation we record the artist on the song level as contributing_artist and on the album level we set it to various artists.

We present the album in the following manner.

In the Artist view
contributing_artist->album, Issue is, songs are still being separated.

In the Album view
variousArtists->album.

The issue is that the album is still not being presented in the artist section, and even if we were to implement in the Artist view variousArtist->album it still would not be listed under the albumArtist.

Suggested solution

1. We always record on the song level the contributing_artist, every song has one.
2. We also record the albumArtist on the song level, and if a albumArtist is not present we set it to the contributing_artist.
3. we continue recording if a song is part of a compilation as we do now,

In the views we will present them as follows.

In the Artist view
albumArtist->albums, a possible issue might be if a album has songs with different albumArtist [have yet to see one myself], in that case we still have the compilation column and if is_compilation we then do variousArtits->album.

In the Album view
albumArtist->album

Of course on the song item we display the contributing_artist.

In conclusion, I think there are ways of solving compilation albums while removing much of the complexity that there seems to be around it.

Originally created by @BernardGoldberger on GitHub (Aug 11, 2016). Original GitHub issue: https://github.com/koel/koel/issues/403 I might be in over my head, but I think the solution for compilation has been somewhat over complicated. [please correct me if I'm wrong] ## Original implementation We record artist info at the album level, which presented an issue when it came to compilation albums as it would separate the song into multiple albums, this was caused by albums being depended on Artists `artist->album->song` ## Current solution We always ignore song artist and simply store that at the album level We use the `albumArtist` tag to determine if a song is part of compilation album. **If it is part of a compilation** we record the artist on the song level as `contributing_artist` and on the album level we set it to `various artists`. We present the album in the following manner. **In the Artist view** `contributing_artist->album`, **Issue** is, songs are still being separated. **In the Album view** `variousArtists->album`. The issue is that the album is still not being presented in the artist section, and even if we were to implement in the Artist view `variousArtist->album` it still would not be listed under the albumArtist. ## Suggested solution 1. We always record on the song level the `contributing_artist`, every song has one. 2. We also record the `albumArtist` on the song level, and if a `albumArtist` is not present we set it to the `contributing_artist`. 3. we continue recording if a song is part of a compilation as we do now, In the views we will present them as follows. **In the Artist view** `albumArtist->albums`, a possible issue might be if a album has songs with different albumArtist [have yet to see one myself], in that case we still have the `compilation` column and if `is_compilation` we then do `variousArtits->album`. **In the Album view** `albumArtist->album` Of course on the song item we display the `contributing_artist`. ## In conclusion, I think there are ways of solving compilation albums while removing much of the complexity that there seems to be around it.

kerem 2026-02-26 02:32:42 +03:00

• closed this issue
• added the
  [Status] Needs Review
  label

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (Aug 11, 2016):

Thanks for the proposal. You're absolutely right, the "compilation albums" feature is buggy and over complicated, admittedly due to my short sight at the beginning of the project. Solving the problem from scratch (like what you proposed above, even though I'd need some time to wrap my head around it), though, is not the biggest issue; keeping the migration path simple and straightforward is. The more changes we introduce into the data structure, the less smooth migration becomes.

With that said, the proposal looks promising. I'll spend the next couple of days to think about it when I have time. Thanks again for the contribution 👍

<!-- gh-comment-id:239062591 --> @phanan commented on GitHub (Aug 11, 2016): Thanks for the proposal. You're absolutely right, the "compilation albums" feature is buggy and over complicated, admittedly due to my short sight at the beginning of the project. Solving the problem from scratch (like what you proposed above, even though I'd need some time to wrap my head around it), though, is not the biggest issue; keeping the migration path simple and straightforward is. The more changes we introduce into the data structure, the less smooth migration becomes. With that said, the proposal looks promising. I'll spend the next couple of days to think about it when I have time. Thanks again for the contribution 👍

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 11, 2016):

Let's take an example here, with a virtual album Classical music with 2 songs (Vivaldi - Summer, Mozart - Requiem). The usual tags you'll find in the files are: album which will be set to Classical Music for both and artist (one will be Vivaldi and the other Mozart).

Currently, it shows twice in the album list because there are 2 different artists (each containing a single song)
In your proposal, what would be the albumArtist ?
In the artist view, should it be listed twice under Mozart and Vivaldi or only once under Various Artists ?

<!-- gh-comment-id:239310721 --> @X-Ryl669 commented on GitHub (Aug 11, 2016): Let's take an example here, with a virtual album `Classical music` with 2 songs (`Vivaldi - Summer`, `Mozart - Requiem`). The usual tags you'll find in the files are: `album` which will be set to `Classical Music` for both and `artist` (one will be `Vivaldi` and the other `Mozart`). Currently, it shows twice in the album list because there are 2 different artists (each containing a single song) In your proposal, what would be the `albumArtist` ? In the artist view, should it be listed twice under `Mozart` and `Vivaldi` or only once under `Various Artists` ?

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 11, 2016):

@> In your proposal, what would be the albumArtist?

Well, that depends on what the albumArtist tag is, see example below where there are different artists for each song but the same albumArtist

However, in your case a virtual album I wouldnt expect there to be a albumArtist so it will be presented under variousArtists.

You do bring up a valid point that I forgot to mention,

should it be listed twice under Mozart and Vivaldi

As I said this would be listed under variousArtists, but, what if someone wants to play all the music by Mozart? why should the particular song not be part of the play list?

So, personally I'm open to the idea that any given song should always be displayed under the contributing_artist even if its already listed under the albumArtist.

Explanation

As I wrote above in the artist view we would present albumArtist->album which mean that it will be listed only under variousArtits.
What we could do in addition to that is, that once we click on an artist, technically speaking its an artistID, so in addition to "grouping" all the albums that the artistId is the albumArtist for, we also list any songs that ArtistID is thecontributing_artist`.

With that, in your case, it will be listed under VariousArtists, but if you click on Mozart it will be listed there as well under the Album Classical music.

<!-- gh-comment-id:239328086 --> @BernardGoldberger commented on GitHub (Aug 11, 2016): @> In your proposal, what would be the `albumArtist`? Well, that depends on what the `albumArtist` tag is, see example below where there are different artists for each song but the same `albumArtist`  However, in your case a **virtual album** I wouldnt expect there to be a `albumArtist` so it will be presented under `variousArtists`. You do bring up a valid point that I forgot to mention, > should it be listed twice under Mozart and Vivaldi As I said this would be listed under `variousArtists`, but, what if someone wants to play all the music by Mozart? why should the particular song not be part of the play list? So, personally I'm open to the idea that any given song should always be displayed under the `contributing_artist` even if its already listed under the `albumArtist`. **Explanation** As I wrote above in the artist view we would present `albumArtist->album` which mean that it will be listed only under `variousArtits`. What we could do in addition to that is, that once we click on an artist, technically speaking its an `artistID`, so in addition to "grouping" all the `albums` that the `artistId` is the `albumArtist` for, we also list any songs that `ArtistID is the`contributing_artist`. With that, in your case, it will be listed under `VariousArtists`, but if you click on Mozart it will be listed there as well under the Album `Classical music`.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 12, 2016):

I'm not sure I've my songs tagged with albumArtist or contributingArtistbut simply artist and album, and I think I'm unlikely to retag all of them like this. Thus, I don't understand how the scheme you are proposing would work.

<!-- gh-comment-id:239361889 --> @X-Ryl669 commented on GitHub (Aug 12, 2016): I'm not sure I've my songs tagged with `albumArtist` or `contributingArtist`but simply `artist` and `album`, and I think I'm unlikely to retag all of them like this. Thus, I don't understand how the scheme you are proposing would work.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 14, 2016):

artist and contributingArtist are the same, you can use a tag editor software to see if you have any additional tags on the song.

You can use something like MP3TAG.

<!-- gh-comment-id:239685694 --> @BernardGoldberger commented on GitHub (Aug 14, 2016): `artist` and `contributingArtist` are the same, you can use a tag editor software to see if you have any additional tags on the song. You can use something like [MP3TAG](http://www.mp3tag.de/en/download.html).

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 14, 2016):

Ok, I didn't know about it.
But for album ? If I have an album for an artist, albumArtist will not be set (album will). I don't want all my albums been located under "Various Artist".

<!-- gh-comment-id:239694069 --> @X-Ryl669 commented on GitHub (Aug 14, 2016): Ok, I didn't know about it. But for album ? If I have an album for an artist, `albumArtist` will not be set (`album` will). I don't want all my albums been located under "Various Artist".

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 14, 2016):

We also record the albumArtist on the song level, and if a albumArtist is not present we set it to the contributing_artist.

<!-- gh-comment-id:239694580 --> @BernardGoldberger commented on GitHub (Aug 14, 2016): > We also record the `albumArtist` on the song level, and if a `albumArtist` is not present we set it to the contributing_artist.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (Aug 15, 2016):

I don't think we need to set albumArtist at the song level, as we can always refer to $song->album->artist_id. In other words, if I get it right, the new solution has one critical difference: contributing_artist_id is always present, and refers to the real performing artist. With this, we can always rely on this column for artist information, and album_id for album information.

Migration should also be straightforward if this is the case. @bdgold can you confirm my understanding?

<!-- gh-comment-id:239814276 --> @phanan commented on GitHub (Aug 15, 2016): I don't think we need to set `albumArtist` at the song level, as we can always refer to `$song->album->artist_id`. In other words, if I get it right, the new solution has one critical difference: `contributing_artist_id` is always present, and refers to the real performing artist. With this, we can always rely on this column for artist information, and `album_id` for album information.  Migration should also be straightforward if this is the case. @bdgold can you confirm my understanding?

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 15, 2016):

@phanan consider the following 2 scenarios.

1. Having an album that each song has a different contributing_artist but no albumArtist is present.
2. Having an album that has conflicting albumArtist's between the songs.

My thought was that if we record albumArtist on the song level we would be able to detect them and place the Album under variousArtist's in the view.

<!-- gh-comment-id:239819265 --> @BernardGoldberger commented on GitHub (Aug 15, 2016): @phanan consider the following 2 scenarios. 1. Having an album that each song has a different `contributing_artist` but no `albumArtist` is present. 2. Having an album that has conflicting `albumArtist`'s between the songs. My thought was that if we record `albumArtist` on the song level we would be able to detect them and place the Album under `variousArtist`'s in the view.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 15, 2016):

@phanan I see that you included Genre, could https://github.com/phanan/koel/pull/318 be considered again? especially Year.

<!-- gh-comment-id:239821594 --> @BernardGoldberger commented on GitHub (Aug 15, 2016): @phanan I see that you included `Genre`, could https://github.com/phanan/koel/pull/318 be considered again? especially `Year`.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (Aug 15, 2016):

@bdgold There shouldn't be the case of one album with different album artists. That just doesn't make sense, and Koel's parser will create multiple albums instead.

<!-- gh-comment-id:239824120 --> @phanan commented on GitHub (Aug 15, 2016): @bdgold There shouldn't be the case of one album with different album artists. That just doesn't make sense, and Koel's parser will create multiple albums instead.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 15, 2016):

I agree that even if it would, its a failure on the users side, I was just thinking of the "what if".

What about the other scenario?

<!-- gh-comment-id:239824978 --> @BernardGoldberger commented on GitHub (Aug 15, 2016): I agree that even if it would, its a failure on the users side, I was just thinking of the "what if". What about the other scenario?

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (Aug 15, 2016):

For the other scenario, we have a default "Various Artists" as the album artist, no?

<!-- gh-comment-id:239828099 --> @phanan commented on GitHub (Aug 15, 2016): For the other scenario, we have a default "Various Artists" as the album artist, no?

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 15, 2016):

Ah, Correct.

<!-- gh-comment-id:239828788 --> @BernardGoldberger commented on GitHub (Aug 15, 2016): Ah, Correct.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 18, 2016):

If a song as the same album tag as some other song but a different contributing_artist, then can the album be marked as a compilation automatically ?

Said differently, is it correct to consider the album name as a unique key to an album id ?

I've numerous compilations where the songs don't have the compilation or part_of_compilation tag, and it's a pain to select all the songs in the GUI to click the "is a compilation" checkbox each time I'm syncing the library.

<!-- gh-comment-id:240748441 --> @X-Ryl669 commented on GitHub (Aug 18, 2016): If a song as the same `album` tag as some other song but a different `contributing_artist`, then can the album be marked as a compilation automatically ? Said differently, is it correct to consider the album name as a unique key to an album id ? I've numerous compilations where the songs don't have the `compilation` or `part_of_compilation` tag, and it's a pain to select all the songs in the GUI to click the "is a compilation" checkbox each time I'm syncing the library.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 18, 2016):

I'm asking this, because I could not figure out what way is proper.
Currently, if you have songs like this:

1. Title:One Artist:Bob Compilation:1 Album:Live 2014 Path: /path/to/Festival/Live 2014/One.mp3
2. Title:Two Artist:Alice Compilation:1 Album:Live 2014 Path: /path/to/Festival/Live 2014/Two.mp3
   ...
3. Title:Another Artist:John Compilation:1 Album:Live 2014 Path: /path/to/John/Live 2014/John - Another.mp3
4. Title:Brick Artist:John Compilation:1 Album:Live 2014 Path: /path/to/John/Live 2014/John - Brick.mp3
5. Title:In ft B and John Artist:B Compilation:1 Album:Live 2014 Path: /path/to/John/Live 2014/John - In feat B.mp3

Koel will merge them in a single compilation album with "Various Artist" (which is correct for the 2 first songs, but not the 3 last songs) because compilation tag is set for all of them (cf. line 57 of Album.php).
So, it acts exactly like if album tag was a key to the album table (artist_id will be set to VARIOUS_ID by compilation tag presence).

In that case, why not mark all of them as compilation as soon as an album is the same and artist is different ?

Also, for example for The Pink Floyd, you've numerous album with the same name, they are not a compilation, only the year changes between them (and the year is ignored, AFAIK). Koel will merge all songs in a single album.

<!-- gh-comment-id:240755680 --> @X-Ryl669 commented on GitHub (Aug 18, 2016): I'm asking this, because I could not figure out what way is proper. Currently, if you have songs like this: 1. **Title**:`One` **Artist**:`Bob` **Compilation**:`1` **Album**:`Live 2014` _Path_: `/path/to/Festival/Live 2014/One.mp3` 2. **Title**:`Two` **Artist**:`Alice` **Compilation**:`1` **Album**:`Live 2014` _Path_: `/path/to/Festival/Live 2014/Two.mp3` ... 3. **Title**:`Another` **Artist**:`John` **Compilation**:`1` **Album**:`Live 2014` _Path_: `/path/to/John/Live 2014/John - Another.mp3` 4. **Title**:`Brick` **Artist**:`John` **Compilation**:`1` **Album**:`Live 2014` _Path_: `/path/to/John/Live 2014/John - Brick.mp3` 5. **Title**:`In ft B and John` **Artist**:`B` **Compilation**:`1` **Album**:`Live 2014` _Path_: `/path/to/John/Live 2014/John - In feat B.mp3` Koel will merge them in a single compilation album with "Various Artist" (which is correct for the 2 first songs, but not the 3 last songs) because `compilation` tag is set for all of them (cf. line 57 of `Album.php`). So, it acts exactly like if `album` tag was a key to the album table (`artist_id` will be set to `VARIOUS_ID` by `compilation` tag presence). In that case, why not mark all of them as compilation as soon as an `album` is the same and `artist` is different ? Also, for example for _The Pink Floyd_, you've numerous album with the same name, they are not a compilation, only the `year` changes between them (and the `year` is ignored, AFAIK). Koel will merge all songs in a single album.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 18, 2016):

Or, would the current folder be used to distinguish them, like so (pseudo code):

$artist = Artist::get($info['artist']);

// Check if the current song is part of a compilation
$album = Album::getFromAlbumName($info['album']);
$albumArtist = Album::getArtistFromAlbumName($info['album']);

if ($album->getIsCompilationAttribute()) 
    $isCompilation = true;
else if ($albumArtist->id !== $artist->id && $this->isInSameFolder($album, $albumArtist)) {
    $album->setArtistId(Album::VARIOUS_ID); // Make the previous song a compilation too
    $isCompilation = true;
} 

// Ok, then add the album or fetch it from DB
$album = Album::get($artist, $info['album'], $isCompilation);

<!-- gh-comment-id:240761933 --> @X-Ryl669 commented on GitHub (Aug 18, 2016): Or, would the current folder be used to distinguish them, like so (pseudo code): ``` $artist = Artist::get($info['artist']); // Check if the current song is part of a compilation $album = Album::getFromAlbumName($info['album']); $albumArtist = Album::getArtistFromAlbumName($info['album']); if ($album->getIsCompilationAttribute()) $isCompilation = true; else if ($albumArtist->id !== $artist->id && $this->isInSameFolder($album, $albumArtist)) { $album->setArtistId(Album::VARIOUS_ID); // Make the previous song a compilation too $isCompilation = true; } // Ok, then add the album or fetch it from DB $album = Album::get($artist, $info['album'], $isCompilation); ```

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Aug 18, 2016):

Generally I don't like the idea of using the folder structure to determine organization, but maybe we should implement something for compilation albums.

<!-- gh-comment-id:240766105 --> @BernardGoldberger commented on GitHub (Aug 18, 2016): Generally I don't like the idea of using the folder structure to determine organization, but maybe we should implement something for compilation albums.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Aug 18, 2016):

See PR #414 for an implementation that does that. It's yet to include the changes @phanan proposed 3 days ago for fixing the model too.

<!-- gh-comment-id:240815662 --> @X-Ryl669 commented on GitHub (Aug 18, 2016): See PR #414 for an implementation that does that. It's yet to include the changes @phanan proposed 3 days ago for fixing the model too.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Sep 6, 2016):

@X-Ryl669 in regards to #414 I agree with @phanan that we should not rely on the folder structure.

Although that it would be lumped into variousArtits the individual songs will still be listed under the contributing_artist, the only thing that I see as an issue is that in the album view they will be lumped into one album and probably have duplicate tack numbers.

having sad that, maybe there is a way that we could use the track number to figure out that there are 2 separate albums, I'm not sure though how it would work or be implemented, let me know what you guys think.

<!-- gh-comment-id:245016539 --> @BernardGoldberger commented on GitHub (Sep 6, 2016): @X-Ryl669 in regards to #414 I agree with @phanan that we should not rely on the folder structure. Although that it would be lumped into `variousArtits` the individual songs will still be listed under the `contributing_artist`, the only thing that I see as an issue is that in the album view they will be lumped into one album and probably have **duplicate tack numbers**. having sad that, maybe there is a way that we could use the track number to figure out that there are 2 separate albums, I'm not sure though how it would work or be implemented, let me know what you guys think.

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Sep 7, 2016):

I'm not sure I'm getting it. Can you give an example here ?

<!-- gh-comment-id:245271903 --> @X-Ryl669 commented on GitHub (Sep 7, 2016): I'm not sure I'm getting it. Can you give an example here ?

kerem commented 2026-02-26 02:32:42 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Sep 7, 2016):

Can you give an example here ?

for which part?

<!-- gh-comment-id:245275211 --> @BernardGoldberger commented on GitHub (Sep 7, 2016): > Can you give an example here ? for which part?

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@alex-phillips commented on GitHub (Sep 7, 2016):

@bdgold As far as the tracks being lumped into one album, would adding the metadata for album year fix this issue? I've run into an issue where I have 2 releases of an album (ex: Pink Floyd's The Wall (1979) and The Wall Box Set (2011)) where unless the album year is a subsort on the listing, they are listed as track 1, track 1, track 2, track 2.

I have already done the work, it just needs to be agreed upon that it is a useful piece of metadata: https://github.com/phanan/koel/pull/318

<!-- gh-comment-id:245281158 --> @alex-phillips commented on GitHub (Sep 7, 2016): @bdgold As far as the tracks being lumped into one album, would adding the metadata for album year fix this issue? I've run into an issue where I have 2 releases of an album (ex: Pink Floyd's The Wall (1979) and The Wall Box Set (2011)) where unless the album year is a subsort on the listing, they are listed as track 1, track 1, track 2, track 2. I have already done the work, it just needs to be agreed upon that it is a useful piece of metadata: https://github.com/phanan/koel/pull/318

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Sep 7, 2016):

That will work when you have 2 albums from 2 separate years, but in his case they are from same year. Using track numbers will us at the least determine that there is something weird, maybe we can introduce a section to resolve conflicts.

<!-- gh-comment-id:245301385 --> @BernardGoldberger commented on GitHub (Sep 7, 2016): That will work when you have 2 albums from 2 separate years, but in his case they are from same year. Using track numbers will us at the least determine that there is something weird, maybe we can introduce a section to resolve conflicts.

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Sep 7, 2016):

Just my 2 cents, but if you only expect to discriminate a song based on its metadata (and not its folder information), then you must support all metadata (and not only some of them) as a unique key to identify a song. Else, you'll have duplicate and you can't tell which is which (example: Pink Floyd from @alex-phillips).

Also, because it's not convenient to have a folder full of tens of thousands of files, I think most people use folder structure to sort their files (and the OS is encouraging to do so, having 40000 files in a folder takes forever to browse in a file explorer etc...), so ignoring this fact is simply
burying our heads in the sand stupidly. I'm not saying it should be the rule, but I'm saying (like I did in the #414) that in case of conflicts, the file hierarchy is precious and use it to solve it. If you store all your file in a single folder, well, it does not break, you can't tell which is which. But if you do use some hierarchy, then Koel'll be able to sort this out by itself.

The issue with using all metadata comes from the fact that some tags are not clearly defined about what they do/are for, and many song have a different philosophy about what to store in them (if they even store something in them), and this creates conflict (see for example, the albumartist that's set equal to the artist for each song of an album), some tags are missing (like the tracknumber for some songs etc...)

Anyway, why would it have duplicate track number ?
What would be the most convenient way to see the track ? Via the "Various Artist" (is it where you would expect the song ?), or in the original album (and the contributing_artist) only ?
I would prefer the last case.
In that case, when listing the album, you could filter by song id (since there's only a single song in this case), by preferring showing the original contibutingArtist other the Various Artist

IMHO, all of this happens because "artist has one or more album has one or more song" is not always true.

In case of complete changes, then I think the relation "song is in album" and "song is from one or more artist" is the only version that's always true.
So the database should say:

• song : has an id, album_id, title, path, + the rest
• artist: has an id, song_id, name, + the rest, the primary key being the pair idand song_id
• album: has an id, name, year + the rest

When listing by songs, it's easy to join the query and have both the artist + album + song for each song.
When listing by albums, just select the song based on the album id, and join the query to get the artist for each song_id.
When listing by artists, just join the songs based on song_id, and join the query on the album_id for each song found.
A compilation is defined when the number of artists for songs with the same album_id is greater than one (no need to have a column in DB for this, you can deduce it).

<!-- gh-comment-id:245333920 --> @X-Ryl669 commented on GitHub (Sep 7, 2016): Just my 2 cents, but if you only expect to discriminate a song based on its metadata (and not its folder information), then you must support **all** metadata (and not only some of them) as a unique key to identify a song. Else, you'll have duplicate and you can't tell which is which (example: Pink Floyd from @alex-phillips). Also, because it's not convenient to have a folder full of tens of thousands of files, I think most people use folder structure to sort their files (and the OS is encouraging to do so, having 40000 files in a folder takes forever to browse in a file explorer etc...), so ignoring this fact is simply burying our heads in the sand stupidly. I'm not saying it should be the rule, but I'm saying (like I did in the #414) that **_in case of conflicts_**, the file hierarchy is precious and use it to solve it. If you store all your file in a single folder, well, it does not break, you can't tell which is which. But if you do use some hierarchy, then Koel'll be able to sort this out by itself. The issue with using all metadata comes from the fact that some tags are not clearly defined about what they do/are for, and many song have a different philosophy about what to store in them (if they even store something in them), and this creates conflict (see for example, the `albumartist` that's set equal to the `artist` for each song of an album), some tags are missing (like the `tracknumber` for some songs etc...) Anyway, why would it have duplicate track number ? What would be the most convenient way to see the track ? Via the "`Various Artist`" (is it where you would expect the song ?), or in the original album (and the `contributing_artist`) only ? I would prefer the last case. In that case, when listing the album, you could filter by song id (since there's only a single song in this case), by preferring showing the original `contibutingArtist` other the `Various Artist` IMHO, all of this happens because "artist _has one or more_ album _has one or more_ song" is not always true. In case of complete changes, then I think the relation "song _is in_ album" and "song _is from one or more_ artist" is the only version that's always true. So the database should say: - `song` : has an `id`, `album_id`, `title`, `path`, + the rest - `artist`: has an `id`, `song_id`, `name`, + the rest, the primary key being the pair `id`and `song_id` - `album`: has an `id`, `name`, `year` + the rest When listing by songs, it's easy to join the query and have both the artist + album + song for each song. When listing by albums, just select the song based on the album `id`, and join the query to get the artist for each `song_id`. When listing by artists, just join the songs based on `song_id`, and join the query on the `album_id` for each song found. A compilation is defined when the number of artists for songs with the same `album_id` is greater than one (no need to have a column in DB for this, you can deduce it).

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Sep 7, 2016):

Using meta data is not discrimination, its the quite opposite, it allows the song to speak for itself, using the folder structure, is essentially allowing an outsiders influence.
We are planning to bring in more meta data, we just need to figure out which ones are useful, too much is sometimes just too much.

In regards to the folder structure, I understand both sides of the coin, maybe we could compromise and use the .env to enable or disable the feature.

Anyway, why would it have duplicate track number ?

You misunderstood that part I believe, I'm referring too the track number, meaning, if Koel thinks that 2 albums are 1 album, the album will end up having to track #1 and so forth, we could use that to tell us that there are 2 live albums in your case.

The entire last part you wrote I simply don't understand, can you try to clarify more?

<!-- gh-comment-id:245426677 --> @BernardGoldberger commented on GitHub (Sep 7, 2016): Using meta data is not discrimination, its the quite opposite, it allows the song to speak for itself, using the folder structure, is essentially allowing an outsiders influence. We are planning to bring in more meta data, we just need to figure out which ones are useful, too much is sometimes just too much. In regards to the folder structure, I understand both sides of the coin, maybe we could compromise and use the .env to enable or disable the feature. > Anyway, why would it have duplicate track number ? You misunderstood that part I believe, I'm referring too the track number, meaning, if Koel thinks that 2 albums are 1 album, the album will end up having to track `#1` and so forth, we could use that to tell us that there are 2 live albums in your case. The entire last part you wrote I simply don't understand, can you try to clarify more?

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@X-Ryl669 commented on GitHub (Sep 8, 2016):

if Koel thinks that 2 albums are 1 album, the album will end up having to track #1 and so forth, we could use that to tell us that there are 2 live albums in your case.

This problem shall not happen if you use the complete set of metadata instead of a fewer one (like alex's said). If you ignore a single tag that's present in a file, then you'll end up with conflicts and Koel will think songs are similar.
Using the tracknumber will not cut it, since you could have the 2 songs with the same title, tracknumber, album, artist but different discyear. The only way to solve this is not to ignore any tag in the initial file and use all of them for identifying a song.
That's for the parsing part : how to end up with correct information in DB...

The last part of my last comment talks about the internal issue with the current DB layout, currently, Koel's song sorting algorithms expects this relation artist>album>song. This is wrong IMHO, and it's probably the cause for all the mismatch and misorder in the album view.

Because compilation album with different artists exists, because songs with different artists exists, the relation is (obviously) wrong.

It should be split in 2 distinct relations, song are part of album and artist participated in song.
Then you can explain all cases from the basic artist > albums > songs, to more complex compilation album with many songs of different artists.

The database format thus should be changed to reflect this, and I wrote how I would do it if I had to do it.

With such a structure, it would also imply that the /api/data is modified to have 3 main keys (instead of a single one), starting from songs, albums and artists, and remove all the clunky sorting JS code that tries to build album/artist from a list of songs. The sorting would be done by the database with 3 complex queries I've described (that could be cached since the media library does not change often, so it'll even be faster to boot the JS code). The JS code would then follow the "songs" key of the received data when browsing by songs, the "albums" key with browsing by albums, and "artists" key when browsing by artists.

I did this in my fork for folders (except that I created a new route for it that's only fetched on first access, instead of when loading the page), and I think it's clean. You don't pay the cost of downloading the folder structure if you don't use it. The same could be done for albums, artists, genres ?, .... Only the songs must be downloaded once to be refered by UID by other structures.

Please notice that I'm not duplicating the data, since they refer to each other by uid, I'm just writing down the relations between element in the JSON object sent (instead of a big 1D list you need to re-parse in JS to figure out the relation between elements, I'm storing the relation in the JSON object and refer to songs by ID).

<!-- gh-comment-id:245552005 --> @X-Ryl669 commented on GitHub (Sep 8, 2016): > if Koel thinks that 2 albums are 1 album, the album will end up having to track #1 and so forth, we could use that to tell us that there are 2 live albums in your case. This problem shall not happen if you use the complete set of metadata instead of a fewer one (like alex's said). If you ignore a single tag that's present in a file, then you'll end up with conflicts and Koel will think songs are similar. Using the `tracknumber` will not cut it, since you could have the 2 songs with the same `title`, `tracknumber`, `album`, `artist` but different `discyear`. The **only** way to solve this is **not to ignore** any tag in the initial file and use all of them for identifying a song. That's for the parsing part : how to end up with correct information in DB... The last part of my last comment talks about the internal issue with the current DB layout, currently, Koel's song sorting algorithms expects this relation artist>album>song. This is wrong IMHO, and it's probably the cause for all the mismatch and misorder in the album view. Because compilation album with different artists exists, because songs with different artists exists, the relation is (obviously) wrong. It should be split in 2 distinct relations, **song** _are part of_ **album** and **artist** _participated in_ **song**. Then you can explain all cases from the basic artist > albums > songs, to more complex compilation album with many songs of different artists. The database format thus should be changed to reflect this, and I wrote how I would do it if I had to do it. With such a structure, it would also imply that the `/api/data` is modified to have 3 main keys (instead of a single one), starting from songs, albums and artists, and remove all the clunky sorting JS code that tries to build album/artist from a list of songs. The sorting would be done by the database with 3 complex queries I've described (that could be cached since the media library does not change often, so it'll even be faster to boot the JS code). The JS code would then follow the "songs" key of the received data when browsing by songs, the "albums" key with browsing by albums, and "artists" key when browsing by artists. I did this in my [fork](https://github.com/X-Ryl669/koel) for folders (except that I created a new route for it that's only fetched on first access, instead of when loading the page), and I think it's clean. You don't pay the cost of downloading the folder structure if you don't use it. The same could be done for albums, artists, genres ?, .... Only the songs must be downloaded once to be refered by UID by other structures. Please notice that I'm not duplicating the data, since they refer to each other by uid, I'm just writing down the relations between element in the JSON object sent (instead of a big 1D list you need to re-parse in JS to figure out the relation between elements, I'm storing the relation in the JSON object and refer to songs by ID).

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (Sep 9, 2016):

This problem shall not happen if you use the complete set of metadata instead of a fewer one (like alex's said). If you ignore a single tag that's present in a file, then you'll end up with conflicts and Koel will think songs are similar.

Having all tags does not help us if we don't use it, so the question remains, what tags are helpful? we know that year is, hopefully that will be implemented.

An important note is, that even the year tag could just mean that its a compilation of one artists greatest hits, so even here the logic needs to be worked out. Update Actually since its all the same artist it should never be detected as a compilation and therefore not use the year tag.

In regards to redesigning the DB, I'm not a super admin when it comes to it, so I will leave it for @phanan and the others to look at, but I can tell you that we would want the migration process to be simple and work, so take that into account with any proposals.

I hope we can all agree on some things soon and get them implemented, we don't need to fix it all immediately but rather come to agreements, implement, then work on the next thing, and we will ultimately get there.

I will try to compile a summary of all that we discussed, so that we can wrap our heads around all of it.

<!-- gh-comment-id:245992491 --> @BernardGoldberger commented on GitHub (Sep 9, 2016): > This problem shall not happen if you use the complete set of metadata instead of a fewer one (like alex's said). If you ignore a single tag that's present in a file, then you'll end up with conflicts and Koel will think songs are similar. Having all tags does not help us if we don't use it, so the question remains, what tags are helpful? we know that `year` is, hopefully that will be implemented. An important note is, that even the `year` tag could just mean that its a compilation of one artists greatest hits, so even here the logic needs to be worked out. **Update** Actually since its all the same artist it should never be detected as a compilation and therefore not use the year tag. In regards to redesigning the DB, I'm not a super admin when it comes to it, so I will leave it for @phanan and the others to look at, but I can tell you that we would want the migration process to be simple and work, so take that into account with any proposals. I hope we can all agree on some things soon and get them implemented, we don't need to fix it all immediately but rather come to agreements, implement, then work on the next thing, and we will ultimately get there. I will try to compile a summary of all that we discussed, so that we can wrap our heads around all of it.

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (May 7, 2017):

The proposal has been implemented on master branch. @YakovGoldberger if you have time, can you take a look and see if it works according to our discussion? Thanks!

<!-- gh-comment-id:299678864 --> @phanan commented on GitHub (May 7, 2017): The proposal has been implemented on `master` branch. @YakovGoldberger if you have time, can you take a look and see if it works according to our discussion? Thanks!

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (May 7, 2017):

@phanan yes, will take me though a couple of days, I'll keep you posted.

Thank you.

<!-- gh-comment-id:299722457 --> @BernardGoldberger commented on GitHub (May 7, 2017): @phanan yes, will take me though a couple of days, I'll keep you posted. Thank you.

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (May 7, 2017):

@phanan did anything change in the DB? Do i need to run php artisan migrate?

<!-- gh-comment-id:299722575 --> @BernardGoldberger commented on GitHub (May 7, 2017): @phanan did anything change in the DB? Do i need to run `php artisan migrate`?

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (May 8, 2017):

Yes, there are a couple of db changes. Please make a backup before
proceeding.

On Mon, May 8, 2017 at 00:51 YakovGoldberger notifications@github.com
wrote:

@phanan https://github.com/phanan did anything change in the DB? Do i
need to run php artisan migrate?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/phanan/koel/issues/403#issuecomment-299722575, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHrt0rzmMupL2SLu05VD67cXZ5KrvC7wks5r3gSlgaJpZM4Jhvd1
.

<!-- gh-comment-id:299750468 --> @phanan commented on GitHub (May 8, 2017): Yes, there are a couple of db changes. Please make a backup before proceeding. On Mon, May 8, 2017 at 00:51 YakovGoldberger <notifications@github.com> wrote: > @phanan <https://github.com/phanan> did anything change in the DB? Do i > need to run php artisan migrate? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/phanan/koel/issues/403#issuecomment-299722575>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AHrt0rzmMupL2SLu05VD67cXZ5KrvC7wks5r3gSlgaJpZM4Jhvd1> > . >

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (May 8, 2017):

The upgrade commands would be

git fetch
git checkout master
composer install
php artisan koel:init

<!-- gh-comment-id:299750545 --> @phanan commented on GitHub (May 8, 2017): The upgrade commands would be ```bash git fetch git checkout master composer install php artisan koel:init ```

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (May 19, 2017):

Hmm,
@phanan there doesn't seem to be any change, I also tried a test version with a new database, no change.

<!-- gh-comment-id:302737032 --> @BernardGoldberger commented on GitHub (May 19, 2017): Hmm, @phanan there doesn't seem to be any change, I also tried a test version with a new database, no change.

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@phanan commented on GitHub (May 19, 2017):

No change is a good thing, it means functionality wise the app is still OK.

On Fri, May 19, 2017 at 22:38 YakovGoldberger notifications@github.com
wrote:

Hmm,
@phanan https://github.com/phanan there doesn't seem to be any change,
I also tried a test version with a new database, no change.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/phanan/koel/issues/403#issuecomment-302737032, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHrt0gfwVkyZpZz-NW_Lpj2qR4hr4o6Kks5r7beFgaJpZM4Jhvd1
.

<!-- gh-comment-id:302753109 --> @phanan commented on GitHub (May 19, 2017): No change is a good thing, it means functionality wise the app is still OK. On Fri, May 19, 2017 at 22:38 YakovGoldberger <notifications@github.com> wrote: > Hmm, > @phanan <https://github.com/phanan> there doesn't seem to be any change, > I also tried a test version with a new database, no change. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/phanan/koel/issues/403#issuecomment-302737032>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AHrt0gfwVkyZpZz-NW_Lpj2qR4hr4o6Kks5r7beFgaJpZM4Jhvd1> > . >

kerem commented 2026-02-26 02:32:43 +03:00

Author

Owner

Copy link

@BernardGoldberger commented on GitHub (May 19, 2017):

True 👍

<!-- gh-comment-id:302822220 --> @BernardGoldberger commented on GitHub (May 19, 2017): True :+1:

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

dependabot/composer/phpunit/phpunit-12.5.22

dependabot/npm_and_yarn/dompurify-3.4.0

dependabot/npm_and_yarn/vite-plus-0.1.17

dependabot/composer/phpseclib/phpseclib-3.0.51

release

1889-duplicate-upload-detection

test/home-screen-empty-to-content

fix/exclude-songless-albums-from-recently-added

refactor/laravel-prompts

fix/wma-cover-art-exception

fix/remove-redundant-seed-step

chore/upgrade-laravel-13

chore/upgrade-vue-3.5.29

test/phase-7-components

dbg-2142

demo-fix

debug-mysql

trusthosts

seek

fix-equalizer

sentry

invite-user

remove-v6-obsolete

fix/song-list

feat/paths-filter

fix/home

fix/footer

feat/progressive

php81

dev/public-playlists

cy

feat/l7

dependabot/composer/pusher/pusher-php-server-4.1.4

dependabot/composer/laravel/framework-5.8.38

dependabot/composer/jackiedo/dotenv-editor-1.1.1

renovate/pin-dependencies

actions

api-doc

feat/recently-played

fix-tests

fix-cover-page

upload

stylejs-196

compilation

vuex

android-notif

nojquery

demo

vue2

2.0

1.1

v9.1.1

latest

v9.1.0

v9.0.0

v8.3.1

v8.3.0

v8.2.0

v8.1.0

v8.0.0

v7.15.1

v7.15.0

v7.14.0

v7.13.0

v7.12.0

v7.11.0

v7.10.4

v7.10.3

v7.10.2

v7.10.1

v7.10.0

v7.9.0

v7.8.1

v7.8.0

v7.7.1

v7.7.0

v7.6.3

v7.6.2

v7.6.1

v7.6.0

v7.5.2

v7.5.1

v7.5.0

v7.4.2

v7.4.1

v7.4.0

v7.3.1

v7.3.0

v7.2.2

v7.2.1

v7.2.0

v7.1.0

v7.0.12

v7.0.11

v7.0.10

v7.0.9

v7.0.8

v7.0.7

v7.0.6

v7.0.5

v7.0.4

v7.0.3

v7.0.2

v7.0.1

v7.0.0

v6.12.1

v6.12.0

v6.11.5

v6.11.4

v6.11.3

v6.11.2

v6.11.1

v6.11.0

v6.10.0

v6.9.0

v6.8.5

v6.8.4

v6.8.3

v6.8.2

v6.8.1

v6.8.0

v6.7.5

v6.7.4

v6.7.3

v6.7.2

v6.7.1

v6.7.0

v6.6.0

v6.5.3

v6.5.2

v6.5.1

v6.5.0

v6.4.3

v6.4.2

v6.4.1

v6.4.0

v6.3.0

v6.2.2

v6.2.1

v6.2.0

v6.1.0

v6.0.6

v6.0.5

v6.0.4

v6.0.3

v6.0.2

v6.0.1

v6.0.0

v0.0.0-beta

v5.1.14

v5.1.13

v5.1.12

v5.1.11

v5.1.10

v5.1.9

v5.1.8

v5.1.7

v5.1.6

v5.1.5

v5.1.4

v5.1.3

v5.1.2

v5.1.1

v5.1.0

v5.0.2

v5.0.1

v5.0.0

v4.4.0

v4.3.1

v4.3.0

v4.2.2

v4.2.1

v4.2.0

v4.1.1

v4.1.0

v4.0.0

v3.7.2

v3.7.1

v3.7.0

v3.6.2

v3.6.1

v3.6.0

v3.5.5

v3.5.4

v3.5.3

v3.5.2

v3.5.1

v3.5.0

v3.4.1

v3.4.0

v3.3.1

v3.3.0

v3.2.0

v3.1.1

v3.1.0

v3.0.1

v3.0.0

v2.2.1

v2.2.0

v2.1.0

v2.0.2

v2.0.1

v2.0.0

v1.1.2

v1.1.1

1.0.0-beta

Labels

Clear labels   

Authentication

  

Dependencies

  

Documentation

  

Feature Request

  

Flac

  

Help Wanted

  

Installation/Setup

  

Integration

  

Mobile

  

PR Welcome

  

Pending Release

  

Performance

  

Playlist

  

S3

  

Search

  

Sync

  

[Pri] Low

  

[Pri] Normal

  

[Status] Keep Open

  

[Status] Needs Author Reply

  

[Status] Needs Review

  

[Status] Stale

  

[Status] Will Implement

  

[Type] Blessed

  

[Type] Bug

  

[Type] Duplicate

  

[Type] Enhancement

  

[Type] Help Request

  

[Type] Question

  

[Type] Task

  

pull-request

Mirrored from GitHub Pull Request

No labels

Authentication

Dependencies

Documentation

Feature Request

Flac

Help Wanted

Installation/Setup

Integration

Mobile

PR Welcome

Pending Release

Performance

Playlist

S3

Search

Sync

[Pri] Low

[Pri] Normal

[Status] Keep Open

[Status] Needs Author Reply

[Status] Needs Review

[Status] Stale

[Status] Will Implement

[Type] Blessed

[Type] Bug

[Type] Duplicate

[Type] Enhancement

[Type] Help Request

[Type] Question

[Type] Task

pull-request

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/koel-koel#290

No description provided.