Amarok/Proposals/Song Abstraction:2.0

From KDE Community Wiki
Revision as of 11:45, 8 December 2012 by Mamarok (talk | contribs) (add acknowledgment that was left out from original page and missing tags)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Thanks to Jud Craft for most of the text in this proposal.

The Problem

There are many reasons to keep around multiple copies of a song, in different formats. Chiefly, you may prefer to keep a FLAC copy for best quality, but an MP3 copy for your media players; and transcoding on-the-fly every time for every song just isn't worth it.

You may even keep an OGG collection on your hard drive, while you have higher-quality FLAC files stored on an extra drive at your workstation.

Currently when you attach to these sources of (identical songs, but different formats) your Amarok collection is populated with four or five different copies of the same song.

Conceptual Solution

Amarok should abstract the idea of a "Song" (or Track, they are the same thing in this document) even further then it does now. You should be able to associate multiple files, or sources, that actually provide the song.

For example, I would want to listen to the MP3 songs on my laptop. But at home, hooked up to my docking station, I'd rather pump out the pure FLAC files from my awesome speaker setup. A type of song-file-retrieval priority would be interesting. I'd just click the song, and Amarok would play whatever it has, with maybe a preference for the better copy.

In addition, whenever you change one song from one format to another, of course, most transcoding is not completely lossless: going from MP4 to MP3 or OGG to MP3 (for an iPod) may not be perfect, and it would be shame to throw away the old file even though I want to use the new one. Having Amarok manage all file formats on a per-song basis would help organize this greatly.

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.

Vocabulary

Song - A particular song. This is the meta concept of the song and it's associated metadata. This metadata includes traditional tags: Title, Artist, Album, but also it's Sources

Source - An "implementation" of a Song. The file on disk representing a Song. A source always represents one song, and is tied to a particular format (MP3, Flac, etc). A source will usually have its Song's metadata embedded within it.

Technical Solution

Background Architecture

Identifying "Songs"

This feature hinges around Amarok's ability to recognize that two individual music files are the same Song, and do so with a high degree of accuracy. In fact, Amarok should never mistakenly identify two music files as the Same song if they aren't. Such behavior would appear to the user as disappearing Songs in Amarok (while the files on disk are still present).

There are two possible mechanisms for identifying duplicate files.

  • Tag matching
  • Algorithmic Analysis

Tag matching If any number of files of different formats have the same title, album, and artist, then they are grouped under one Song.

Corner Case 1: Files have identical title, album, and artist tags, but different years because the albums are different (e.g., remasters, re-releases). One possible solution is to match the year in addition to title, album, and artist, but often the year tag is missing.

Proposed Solution: Group files that have identical title, album, artist, and year tags. If the year tag is missing arbitrarily group the file.

Algorithmic Analysis Perform an analysis of each file to determine generate a song id. Group each file that has the same song id.

This feature requires development of the analysis engine, and which is still in the early stages. This method listed here for completeness.

The UI

This feature should create few additional UI elements. For the large part this feature should function transparently from the point of view of the user.

Configuration Changes

There should be an established playback priority order under the "Playback" heading in the Configuration dialog. Under the heading "Source Priority" there will be a list of various formats (flac, ogg, mp3, etc), and the user orders them (shifts up/down?) in the order they wish them to play. There should be sensible defaults, an auto-rank (that puts FLACs before MP3s for example), as well as a setting for bitrate detection setting: "Play highest bit rate file" That way it will choose a higher quality ogg over an mp3.

For the casual format-agnostic listener, there is nothing betrayed at all. The Source Priority list 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."

Track Details Changes

On a song's "Edit Details" dialog there will be another tab labeled "Sources", 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.

Optionally: On this same "Sources" tab, there will be options that allow the user to manually associate and dissociate particular Sources from the Song. This feature is questionable.

Optionally: On this same "Sources" tab, in addition to the list of available files and the "Preferred Format Source" 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. (This assumes some sort of encoding mechanism in Amarok)