Version: 2.1-SVN (Debian 2.0.60+svn934288-1) (using 4.2.1 (KDE 4.2.1), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.28 When amarok deals with a song with an almbumartist tag, it treats it as an artist tag, which is wrong, but could be seen as a temporary workaround for the broken handling of "various artist" thing. But the real problem is that when I edit tags from within amarok, it's the artist tag that gets edited. Since albumartist ovverrides artist, you can't actually modify the name of the artist displayed in amarok.
Search for duplicates before submitting reports. *** This bug has been marked as a duplicate of bug 172953 ***
I don't see how this is a duplicate of the other bug listed. Especially since this specific behavior is still present in 2.1.90 (a.k.a 2.2 RC 1) and the other bug was supposedly closed months ago. A single track should display the contents of the artist tag for the song artist, not the albumartist tag. To replicate this bug, open an mp3 file with the kid3 program. Edit the ID3v2.x tag to have "Singer" in the artist field and "Album Group" in the albumartist field. Save and close the file. Now open the same mp3 in Amarok. It will display the track with an artist name of "Album Group". If you edit the artist field within Amarok to say "Whalin Mama" and save it, Amarok will still proudly display "Album Group" as the artist. If you open the mp3 back up with kid3 after editing in Amarok, it will now have "Whalin Mama" as the artist in *all* versions of the tag and "Album Group" as the albumartist. In other words, Amarok reads albumartist to be the track artist, but saves the track artist in the artist tag. The expected behavior is for Amarok to read the artist field to determine the track artist and albumartist field to determine the album artist. It should also display separate fields for the artist and albumartist in the tag editor. The save behavior is correct, but appears incorrect from the view of the user, because of the faulty read on the artist field. Finally, compilation albums could be detected simply by comparing the albumartist field to a few strings such as "Various" or "Various Artists" or "Soundtrack", etc. You could even allow the user to override the default strings included and compare the albumartist to the user provided strings. I can see how this bug would compound the problems of bug 172953; however, they are separate bugs. This is a single issue and should have a fairly simple fix. If handled correctly, it should simplify your code for dealing with the other bug of not handling compilation albums correctly.