[RFC] MP3 player management via Rhythmbox etc.

[John Moser]

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.