Just wanted to say it's currently my intention to modify this...  I'm totally new to rhythmbox so any suggestions would help allot.

http://mail.gnome.org/archives/rhythmbox-devel/2010-November/msg00007.html gives some more insights about this (and the whole thread is an interesting read). Matt, out of curiosity, what format are you using that unnecessarily gets transcoded?

I, personally have mostly flac audio, but also some media already encoded in Apple Lossess.  I would rewrite the code myself, but I'm not much of a C programmer, and I don't have enough time at the moment to start a new project, was just hoping someone else might like Lossless, and would be willing to help.

The iPhone can't play flac as far as I know, so these files are reencoded which is the behaviour you expect, right? Are the Apple Lossless files being reencoded too when being transferred to the iPhone?

Exactly, the flac files should be, and are reencoded.  However, I would like to reencode them to apple lossless (doable via ffmpeg/ffenc), however Rhythmbox only allows mp3 and aac audio to be transferred to an iPod/iPhone.  The ALAC (Apple Lossless) should not be reencoded.  It all comes down to Rhythmbox's hardcoding of mp3 and aac in its code.  
Just a suggestion, would it also not be smart to simply implement the supported formats check into libgpod instead, then wrap arround them in Rhythmbox, so that the code would not have to be changed in Rhythmbox if the iPod's storage of supported formats changes in the future.  Just an idea, not sure if the libgpod coders would be willing to do that, but someone might file a feature request there just in case.

That's a trickier question...  

At that point what you would need to do is 
1) Get a list of mime types that are acceptable on the device.
2) Query the user as to which is preferable.

My immediate assumption would be to re-encode to what I'd hope to be the most 'common' format... Probably not ALAC...

Rhythmbox already allows the user to chose which format they wish to encode to.  It just verifys that a format on the user's list in Preferences->Music->Preferred format is in the device's supported list and uses (I'm assuming) the first one on the list.  In other words if all formats supported were added to the supported list, a user could chose whatever format they wished.  This works for me in forcing all music to be encoded in MP3 320 kbps instead of the default quality, and in rhythmbox -D encoder, you can see Rhythmbox checking mp3 and aac against all the user's listed formats.

That would be an example of something I didn't know.

Thank you,

Gary

And thats about all I know, thanks for doing this.

A mime-type for alac could be added in the hardcoded list, I'm not sure which one to use though :)

It could be, however remember the ALACodec didn't come out until 2004, at which point there had already been several iPods.  Also note that the very first iPod did not support aac.  Although I have no idea if Rhythmbox cares to support the first iPod, having aac in the list could cause issues for a tiny number of people (maybe like 1 or 2).  It would be much better to have the list generated based on the model, and not hardcoded for all models.

Well, people with older ipods could just manually force mp3s, and I'd tend to say that we can wait until we get complaints from such people before going out of our way to make things 100% perfect.
I totally agree with you that not hardcoding the list would be a lot better, but adding a new field in the list is a 1 line change, querying the iPod for the formats it supports involves a lot more work :)

Considering the default (on Ubuntu, and I'm assuming others is MP3), I suppose it would not be too terrible to add 
ret = g_list_prepend (ret, g_strdup ("audio/x-alac"));
to line 1960 in /plugins/ipod/rb-ipod-source.c.  Also it might not be terrible to add wav and aiff to the list, as they are (as far as I can tell) supported by all iPod models since the original.  

Gary Lucas, how far have you gotten, and does it look difficult, or will it be a simple addition to do this properly?

Well it's not simple.

The problem is that codec's are listed in the control file, not mime-types which is what we're looking for here.

My iPhone has the following codec's supported:
<key>AudioCodecs</key>
	<dict>
		<key>AAC</key>
		<dict>
			<key>AppleDRM</key>
			<true/>
			<key>LC</key>
			<dict>
				<key>PerceptualNoiseSubsitution</key>
				<true/>
				<key>VariableBitRate</key>
				<true/>
			</dict>
			<key>MaximumSampleRate</key>
			<integer>48000</integer>
		</dict>
		<key>AIFF</key>
		<dict>
			<key>MaximumBitDepth</key>
			<integer>16</integer>
			<key>MaximumSampleRate</key>
			<integer>48000</integer>
			<key>Mono</key>
			<true/>
			<key>Multichannel</key>
			<false/>
			<key>Stereo</key>
			<true/>
		</dict>
		<key>AMR</key>
		<dict>
			<key>Codec</key>
			<string>samr</string>
			<key>MaximumBitDepth</key>
			<integer>16</integer>
			<key>MaximumSampleRate</key>
			<integer>8000</integer>
			<key>Mono</key>
			<true/>
			<key>Multichannel</key>
			<false/>
			<key>Stereo</key>
			<false/>
		</dict>
		<key>AppleLossless</key>
		<dict>
			<key>AppleDRM</key>
			<true/>
			<key>MaximumBitDepth</key>
			<integer>32</integer>
			<key>MaximumBitDepthUntruncated</key>
			<integer>16</integer>
			<key>MaximumSampleRate</key>
			<integer>48000</integer>
			<key>Mono</key>
			<true/>
			<key>Multichannel</key>
			<false/>
			<key>Stereo</key>
			<true/>
		</dict>
		<key>Audible</key>
		<dict>
			<key>AAC</key>
			<true/>
			<key>Type1</key>
			<false/>
			<key>Type2</key>
			<true/>
			<key>Type3</key>
			<true/>
			<key>Type4</key>
			<true/>
		</dict>
		<key>MP3</key>
		<dict>
			<key>MaximumDataRate</key>
			<integer>320</integer>
			<key>MaximumSampleRate</key>
			<integer>48000</integer>
			<key>Mono</key>
			<true/>
			<key>Stereo</key>
			<true/>
		</dict>
		<key>WAV</key>
		<dict>
			<key>MaximumBitDepth</key>
			<integer>16</integer>
			<key>MaximumSampleRate</key>
			<integer>48000</integer>
			<key>Mono</key>
			<true/>
			<key>Multichannel</key>
			<false/>
			<key>Stereo</key>
			<true/>
		</dict>
	</dict>

Some of those can be easily mapped to mime-types...

Audio/amr etc...

However AppleLossLess, the mime type isn't obvious (Well I think it's 'MP4') but mapping mimetypes to codec's isn't going to be something that we can build once and not worry about down the road... So I'm not sure how the best way to proceed would be...  

I'm currently thinking of building a function to return 'supported_codecs' from libgpod... And then build some mapping logic in Rhythmbox... Probably an XML file so it can be easily modified later...

So
AppleLossLess -> audio/mp4
...
mp3 -> audio/mpeg
aac -> audio/aac

etc...  

Too be honest I'm a little unclear on the difference between mime content types and codecs to start with...  When I began working on this I thought I'd end up with something that mapped immediately...

Does any of that make sense?

Just as a note, I've already tweaked libgpod to return a GList containing the codec names given above... 
ie:
"WAV"
"MP3"
"Audible"
"AppleLossLess"

Etc... 

I was uncertain as to whether it would be worth pulling all the rest of the audio codec information... At least until how the mime - codec translation has been decided...

Apple Lossless is (according to the output of rhythmbox -D encoder using a profile with ffenc_alac ! qtmux stored in a file with the .m4a extension) audio/x-alac.  Either way...

I'd say, if the libgpod devs are willing to include it, the best bet would be add a hard coded list (or possibly conf file?) which maps each codec name to its MIME type.  Then it could be included in other media player without the media player from having to include a new list with new iPod models.  Considering libgpod is updated for new models anyway, it should be much easier for them to keep the list up to date.  I'd assume it would then be simple to include it in rhythmbox, assuming libgpod was tweaked to return the codec name and the MIME type.  

If you, having seen the code for both, think this is the best way to go, I'd say someone files a bug report with libgpod requesting the feature (http://gtkpod.org/bugs/).

Christophe is the author of the chunk of libgpod I was working with.

I'd like to hear his input.

But generally that seems like a good solution...

However I'm unsure of where the mapping should reside...

libgpod appears to only be concerned with iDevices and it doesn't have a notion of Mime Type (or codec at this point).

rhythmbox has both Codec and Mime type notions already in it's base...

I would almost say the mapping (in a perfect world) would exist in some mime library somewhere...

G

Haven't heard from Christophe at all, I'm going to suggest a patch to libgpod, if that happens then we can work at it from the rhythmbox angle.

Right now there's no information coming back from libgpod to Rhythmbox, if this patch happens then you'll get:

AudioCodec: AAC
AudioCodec: WAV
AudioCodec: AMR
AudioCodec: AIFF
AudioCodec: Audible
AudioCodec: AppleLossless
AudioCodec: MP3

Which is at least something to start with.

Hi Gary, sorry for the really late answer :) Returning such a list from libgpod makes sense to me, even if what it contains might have to be improved later on (if that happens, that will probably be in a different function though). I think it would be nice to be able to easily go from what returns libgpod to the encoding profiles described in bug #627476 but I haven't looked into it in details, so I have no idea whether this is realistic ;)

Has anyone tried to transfer an alac file to an ipod using rhythmbox? I've reread this bug, and I'm under the impression that people just guessed it wouldn't work, but noone actually tested it. On the fly conversion from flac to alac is something else, for now I'm only wondering about straight copy of an alac file to an idevice.

No, simply adding ret = g_list_prepend (ret, g_strdup ("audio/x-alac")); to /plugins/ipod/rb-ipod-source.c (dont know the exact spot, I'm not at my computer ata the moment) allows me to dynamically encode to ALAC and play them properly on my iPhone (provided the proper entry for ALAC is in the preferences as a preferred codec).

That also will transfer an ALAC-encoded file properly to an iDevice even if it is not set as a preferred codec.

And without this, you couldn't transfer files already encoded to ALAC?

Yes, without that, Rhythmbox simply assumes ALAC files are not playable by an iDevice and tries to transcode it.  That one line simply adds ALAC to the list of supported formats on iDevices making Rhythmbox act properly and transcode to ALAC or copy the files properly.

I'm missing something here. My understanding is that audio/x-alac is a mimetype used internally by gstreamer, ie its alac plugin generates audio/x-alac data, which is then put in a m4a container. And when I make a few tests with an alac file, I get audio/x-m4a as a type with gst-typefind and audio/mp4 with gvfs-info. audio/x-alac is nowhere to be seen. These 2 mime types are aliases in the shared-mime-info database fwiw.

Starting from that, I'm not sure what magic occurs when you add audio/x-alac :-/

Odd, when I open a m4a alac file in Totem and view its sidebar, it says the file's mime type is audio/x-alac.  Not sure what's going on.  Maybe you aren't using the right encoder?  I use audio/x-raw-int,rate=44100,channels=2 ! ffenc_alac ! qtmux which seems to work fine in Rhythmbox and plays on my iPhone.

I haven't encoded this file, I found one sample file on the net. I couldn't try playback in totem since I don't have the necessary plugins installed :-/ Have you checked gst-typefind on your file?

A file encoded with said gstreamer pipes returns video/quicktime for m4a.  gvfs-info returns audio/mp4.  Really not sure what to tell you.  I'm not really sure where I originally got audio/x-alac, Totem just says "Apple lossless audio".  In any case, it is clearly the right MIME type as it works properly.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/1005.