Re: [Rhythmbox-devel] Audio File Conversion

["James \"Doc\" Livingston" <doclivingston gmail com>]

(accidentally sent to Tom instead of the list)

On Tue, 2006-04-18 at 19:59 +0100, Tom Kirby wrote: 
> > Current CVS already has code to transcoding (converting to different
> > formats) as it's needed to support copying track to portable audio
> > players.
> 
> On that particular subject, it would be good to transcode tracks to
> MP3 if they were being accessed over DAAP by a client that didn't
> support the format of the track. I'm glad to say that RB supports
> playing the remaining WMA files I have on my system from Windows days,
> but the same can't be said of certain DAAP client programs, e.g.
> iTunes.

The only issue with this is that we have no idea what clients support,
so about all you could do is either always transcode, or have a list of
"transcode these formats".

iTunes is particularly sucky, because it ignore the type-information we
send it. If you install the ogg vorbis quicktime codec, iTunes can play
them fine - but it still won't play them streamed over daap because it
assumes that they are are audio/mpeg.

Adding an option to transcode shouldn't be too hard. However, it will
still suck if you have a library of oggs, an iTunes client, and a
patent-hating person who refuses to install a MP3 decoder ;)


> The DAAP code could do with quite a bit more work (seeking still isn't
> implemented properly), and IMHO it should be moved to a plugin. Maybe
> something to tackle in my summer holidays when I'll have time to get
> familiar with the RB codebase...

Yes, it should be a plugin; there is a fairly simple patch in bugzilla
to do this, the only stumbling block is the seeking issue. Currently the
playback class has some hacks in it to allow dodgy seeking over DAAP,
which doesn't really work that well. Turning DAAP into a plugin will
require removing these.


A bit of history on why daap seeking is crap:

Enabling seeking is a trivial change to the code, simply telling
gstreamer that we support it. The reason it isn't enabled is that when
it is, decodebin's type-finding (determining what kind of data it is)
seeks backwards and forwards a few times checking things. Seeking too
many times in short succession causes some servers (notably iTunes) to
kick the client off. So blindly enabling seeking would mean not being
able to access iTunes shares.


For GStreamer 0.10, the solution is re-writing the DAAP source element
to use pull mode, which should let us do seeking in a nice way. However
no-one has done any work on this, as far as I know.


Cheers,

James "Doc" Livingston
-- 
You can lead an idiot to knowledge but you cannot make him think.
You can, however, rectally insert the information, printed on stone
tablets, using a sharpened poker. -- Nicolai in asr