Abstract idea of Song instead of pure file management

[Jud Craft]

The tags, guys, the tags.  You've got metadata to identify a song.
That's what tags are, after all.  No need to come up with an extra
database attribute that basically amounts to more tagging.  The only
exception should be when the sound-analysis code is ever implemented;
I imagine at that point you will want to add a "Sound Identification"
tag or some sort of hash that results from audio analysis, similar to
Musicbrainz's ID (which I assume was the gist of the sound analysis
idea from above).

The ability to associate by tag data or by Sound-ID key tag means that
little change has to be done to the database; the implementation is
merely the retrieval of the list of associated files for each song
from the database with the same metadata.  But, you could on the other
hand redefine the schema to match the abstraction:  Amarok's database
would then keep track of Songs, and keep track of Files, and so many
files would be associated with a Song.  But it is quite possible to
depend on matching tag data to retrieval associated files, and this
means that reforming the schema is not necessary.

(Note:  as I don't know the structure of Amarok's collection database,
I cannot say which method is better, and perhaps you've already
implemented the abstraction of a Song.  Both methods are equally
usable.)

As for user interface, I think there should be as little as possible.
In fact, you shouldn't even be able to tell that you _can_ manually
associate files.  The assumption should be made that a file should be
associated with another only if they're the same song; no other reason
should be allowed.  Any other type of song-association can be saved
for the generic Label system that Amarok already has (which I believe
is still in 2, right?).

The search system should definitely be able to handle filtering by file type.

There should be an established playback priority order, in the options
somewhere.  Perhaps a simple "Format Priority" list which has each
type, and they can be shifted up/down each other.  I think this should
be the greatest extent that the user is aware of the feature.

On a song's properties, I imagine there should be a "Formats" tab,
which lists the available sources for the song.  The advanced user
should be able to specify a unique priority choice per-song, perhaps:
not an entire playback-priority-order, but they can flag _one_ choice
as Preferred Format.  This will take priority over Amarok's built in
format-priority order.  If the preferred is not set, or is not
present, priority order returns to Amarok's defaults.

Ideally there would be no mention of file formats in the collection
view itself; the collection is for songs, after all, not files.
Available files of a song might only be visible from Song Properties.

The benefit of tag-specific association is that files of different
formats can automatically be associated in the database, with no user
intervention required other than conscientious tagging (and since
Amarok is bringing in something 'better than Musicbrainz', I believe
it can be assumed that any file should be tagged.)

On this same "Formats/Files" tab, in addition to the list of available
files and the "Preferred" flag, there should also be a "Make New
Format/Transcode" button perhaps, which will create another version of
the song with the same metadata, keeping it associated of course.

Playing a file will automatically check for a Preferred Format; if not
set, then Amarok will go through the playback format-priority-order
set in Options, and play the first one available.

Any type of ReplayGain functionality implemented natively in Amarok
would have song-focused UI, but file-focused implementation.  Applying
replaygain to a song would apply replaygain to all of that song's
files/formats.

It is important to well-define the vocabulary, for the user
experience.  Files/Formats may be ambiguous/confusing; perhaps "Format
Source" is a better term, with a "Sources" properties tab for each
song, and a "Preferred Format Source" priority list in the Options.
Of course, if the functionality works, it will matter little whether
the tab is called "Sources" or "Formats".

Any automatic transcoding that Amarok will eventually employ (ex, for
Audio Players) should retain the transcoded file (instead of making it
temporarily, copying it, and removing it) and make sure it has the
proper metadata to be associated to the correct song.

The end result is that a user does not have to worry about
association; he merely tags his files or uses Amarok's tagger to tag
them, and Amarok will associate files together for him.  Any files
that he decides to transcode are automatically associated as well.  He
merely may transcode into a format that he likes, and mark which
format he prefers; Amarok handles everything else.

And to the casual format-agnostic listener, there is nothing betrayed
at all.  The Source Priority list in Options could have a brief
description of the available types (FLAC, "Highest quality music
format", WAV, "Highest quality music format", MP3 "Compressed
high-quality music format", OGG "Compressed high-quality music
format", etc.)  The descriptions should be simple enough that a casual
user can say "Well, I want highest quality music to go at the top",
and an advanced user can say "I prefer OGGs to MP3s."

These are just my thoughts.  Automatic association and minimalism in
user interface exposure are key:  Amarok should manage the
association, transcoding, and priority of formats extremely well, but
it should be possible for a normal user to never even notice unless
they go looking for it.