This will come fast and rough; it's a rough idea, not a specification or even a full proposal. This is definitely NOT a design document.
I use Rhythmbox. I don't care about Amarok, or whatever. This will be framed for Rhythmbox; as for Kubuntu and whatever else, just cry "Feature Parity" until someone duplicates work solving the same problem again. That out of the way... I just bought myself an Android phone. Previously I used an Apple iPod. Prior to that, I used the same Apple iPod with Rockbox. All of these function as portable media players. Every single one can be plugged into my machine and show itself as a USB mass storage device. In the case of the Apple iPod, it's managed by a specialized file structure that's handled by libraries from gtkpod; the other two (Rockbox and Android) just scan the media for music files and playlists. I believe that all such devices should operate with a similar management interface tied right into the user's media library-- that is, the music player on their desktop, if sufficiently complex to include a LIBRARY function and multiple managed playlists, should also manage their external media devices. Justification for this will become extremely clear in the course of this e-mail, so just take this as assumption for the moment. The obvious first issue would be the lack of media management for Rockbox- or Android-based devices and other "put MP3 here and I'll find it" style media players. This is also the most trivial: the media player sees external media (flash card, media reader i.e. Motorola 2GB, etc) and allows you to suggest this device may be a music player. Perhaps it also would let you tell it, "Oh, this thing only checks /Music for MP3s," if that is relevant; in fact that is likely an important feature, and storing this configuration (as a file /.portable-media-settings on the device or otherwise) would be an important usability consideration. The second issue is a matter of transcoding. If I drag a bunch of files from Rhythmbox to Brassero and tell it to make an audio CD, it converts FLAC, Vorbis, and MP3 to CDDA for me. No such mechanism exists for burning MP3 CDs for a car CD player (from FLAC, Vorbis, etc); gtkpod will indeed transcode for iPods. This sort of feature needs to be addressed for managed media players; it also needs to be individually configurable, such that I can set i.e. Android based device to use MP3, AAC, or Ogg Vorbis, while a Rockbox device might additionally support FLAC. These are basic features; they're easy to decide and discuss, plop into configuration boxes, and implement. The complexities come when we begin to discuss how exactly to expose things to the user. We also have to decide how to transcode what; if a device supports FLAC, perhaps we don't want to NEVER transcode a FLAC to an MP3, for example, but also not ALWAYS transcode FLAC to MP3 because that would defeat the purpose (the user may as well just configure the device as not supporting FLAC). We have to decide how the user is to get their music onto the device-- the user's library may be 30 gigs, and the device may be 8 gigs. We have to decide how to handle playlists as well. I have a rough concept of all of these things, fortunately. Something palpable can be shaped from this. Let's work on this from a top-down approach, describing the interface before describing technical behaviors. =============== Device Configuration =============== Sufficient to say, if an individual device is an iPod or Roxio or something that we have indiviual code in place to manage, that code should recognize the device already. In the case of inserting an SD card that will go into an Android phone (or such other raw media devices), the UI should allow you to somehow indicate to it that this is indeed a media device which just needs media dropped into it; I have no intention of discussing how to allow SD cards and USB flash drives (car stereos!) to be treated as MP3 player media if the user so wills it, as this raises issues of interface clutter versus burying useful interfaces somewhere out of sight. If the device (or raw memory card) is a raw device as above AND it has a file on it holding configuration from this initial setup process, then it should be automatically recognized in the same way that an iPod would be. As for configuration itself, each device should have a configuration dialog. In this dialog, the user should be able to confugure where the device stores music (default: "/Music"; if this matters, the user must be able to change it). The user should also be able to configure preferred custom formats, including format and settings; as well as their order. Configuration of the formats would be such that lossless formats are automatically preferred above lossy formats; uncompressed lossless formats are preferred above compressed lossless formats (i.e. Wav preferred above FLAC); and no backwards transcoding will ever occurr (i.e. we won't decode MP3 to FLAC, or FLAC to Wav, ever). Quality settings for the formats should be available to the user as well-- in effect, the user should be able to list supported formats as ["WAV"] ["FLAC"] ["Ogg Vorbis" "q10", "Ogg Vorbis" "q5", "Ogg Vorbis" "q3", "Ogg Vorbis" "q2", "Ogg Vorbis" "q1", "AAC", "MP3", "WMA"]. The user should also be able to disable transcoding to any specific codecs, i.e. allow transcoding to Ogg Vorbis but disallow to AAC, MP3, and WMA in a device that supports these. Also, when it is determined that a lossless format shouldbe transcoded, the user should be able to bypass lossless formats in transcoding, or bypass compressed-to-compressed but still enable WAV-to-lossless (for the MOST preferred lossless format). For example, WAV files might be encoded to Ogg Vorbis and never to FLAC; or they may be encoded to FLAC, but never to APE, while APE files will never be encoded to FLAC but rather directly to a lossy format. The above mess can be expressed simply as: - User has a tick box, "Allow encoding from Uncompressed to Lossless" - User has a tick box, "Allow encoding from Lossless to Lossless" - Each format has a tick box, "Allow encoding to this format" - Each format MAY be entered with encoding parameters - A format MAY be entered multiple times, to allow for transcoding to lower bitrates for space reasons (We want to use "Allow encoding to..." because it's more natural, affirming a positive setting on that format rather than a negative; besides, the other two options listed are in the style of check-to-enable) ========= Transcoding ========= When moving files to the player, decisions have to be made about transcoding. These decisions are complex; the simple model as such has MANY nuances that need to be examined by the developer. Some are covered here... very few. First off, transcoding should be a space-triggered event. If I move 4 gigs of FLAC files to a 2 gig device, it stands to reason that I will run out of storage space; however, if it is acceptable to store such files as FLAC, Ogg Vorbis, or MP3, then suddenly transcoding them all to Ogg Vorbis at -q5 (which is what, average 192kbit/s?) will likely cut the space usage from 300M per album to 150M per album, just about fitting it all in 2 gigs. This brings the question of how to make decisions regarding transcoding. The transcoding decisions I provide here are basic, rough, and generalistic; but should work. First off, transcoding should always come from the source. Rhythmbox should know that it's dealing with files from the local computer; it doesn't need to cache transcoded files, because they go directly on the media device. If they go on multiple devices, it could copy them from one to another with the knowledge that the source file was the same. So if a 320kbit/s Ogg Vorbis needs to be transcoded down AND it was generated from a FLAC file in the media library, Rhythmbox should replace it with a 192kbit/s Ogg Vorbis transcoded from the original FLAC file (possibly by copying a 192kbit/s Ogg Vorbis file off another currently connected device). What Rhythmbox should NOT do is encode ~/Music/Tool/Parabola.flac to /media/device/Music/Tool/Parabola.ogg and then later re-encode Parabola.ogg to Parabola.ogg at a lower bitrate. When transcoding, Rhythmbox should determine what is encoded at the highest bitrate (or quality?) and transcode it down. So for example FLAC files will always be encoded to high-quality Vorbis first; Vorbis files transcoded down (from the original copy) from highest bitrate down. So given a FLAC, a -q10 Vorbis, and a -q5 Vorbis, the FLAC would be transcoded to -q10 Vorbis. If space is still needed, one of the -q10 Vorbis files (I don't care which, but the one that started as a FLAC would be transcoded from a copy of the original FLAC) would be transcoded down to -q5 Vorbis. Then the other -q10 would come down. Then we'd start transcoding down to -q3 (or -q4, or whatever the device is configured for). The default operation should be to make a nominal estimate of the bitrate resulting from transcoding to determine the full progression ahead of time, and skip intermediate transcoding; so rather than encoding a FLAC to an Ogg Vorbis 3 times (-q10, -q5, -q3), Rhythmbox should recognize that -q10 would result in a huge file anyway, -q5 would result in 3 files that still don't all fit, and decide to convert the FLAC straight to -q3 (and the -q10 Vorbis to -q3) to bypass re-encoding the -q10 Vorbis to -q5 and the -q5 Vorbis to -q3. Minimal number of operations. This won't be precisely optimal, but it'll be reasonably close. This down-coding leaves some additional configuration considerations when realizing we may have a user that NEVER wants to transcode to MP3, EXCEPT when the file starts as a 320kbit/s MP3 and could be recoded down to 192kbit/s to save space (and the user believes this is acceptable). The user may want all FLAC and WAV files to become Ogg Vorbis; all unsupported lossless to become Ogg Vorbis; but no Ogg Vorbis to become MP3, and no MP3 to become Ogg Vorbis; yet want high-bitrate MP3 to become low-bitrate MP3. Perhaps a "Reduce bitrate without changing formats for formats not encoded to" option, with a shorter name. ============== Media management ============== How do you get songs/playlists/etc onto the device? Select from a list? Drag songs to the device, configure playlists on the device, etc? The short answer is no, you don't. The long answer is I believe more in loading PLAYLISTS to the device, and letting Rhythmbox figure out which songs are implied to then belong on the device. Playlists shouldn't be placed "onto" the device, so much as associated with the device; so dragging a playlist onto a Rockbox device would add it to the Rockbox device, and then changing the playlist's contents would change it on the local host and on every device that uses that playlist. As a special exception, there would be a separate shortlist of "Orphan Songs" not in any playlist. Yes, it's a feature users would demand. If you want (I'd be interested in this), ignore user demands; they'll create a playlist and put those songs in it to bypass this lacking feature. I like that solution better. This is ... about all I have to say on the matter. It's a short, crude, rough explanation of how to handle media, right from "This player only plays MP3s and my whole library is FLACs" and "This isn't an iPod, it's running Rockbox or Android" and all the way down to "How do I select which songs to place on each player?" I know it's a bit complex, and an ugly read; but what do you all think? I have no code to contribute. THIS is my contribution to the matter. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
