Bug 290168

This depends entirely on the phonon backend, which one do you currently use?

GStreamer. The xine backend doesn't seem to be available on Ubuntu Oneiric.

The xine backend is deprecated and unmaintained as the upstream development was stalled. Please make sure you have all gstreamer codec packages installed, espceially the -ugly and -bad packages.
Else you could try the vlc backend which for me works better than the gstreamer one on Kubuntu.

All packages are installed. As I wrote initially, Amarok plays the files just fine as long as they have the extension m4a and not mp4 as 7digital names them. I don't know where in the chain this Windows-style extension filtering is happening.

I doubt this is really an Amarok problem at the core, but I still consider it an error that Amarok silently ignores filetypes the backend presumably rejects.

Did you try with the vlc backend?

Similar problem here, using Kubuntu Oneiric / Amarok 2.5.0 / KDE 4.8.0:

Amarok just ignores any AAC files (regardless of file extension).
* in the file browser, they are not shown
* if I drag them to the playlist nothing happens, no error, no message, only some --debug output (see below)

According to VLC Codec information, the files are "MPEG AAC Audio (mp4a)".

Since KDE Dragon plays the files just fine, I guess the necessary codecs are installed.
I'm using the phonon-gstreamer backend.

The vlc backend for some reason is unusable on my machine, since it always starts to hiss and noise after a few seconds of playback.
(/offtopic: same thing in VLC itself, the only way to get proper sound is to set the audio output module to ALSA, PulseAudio just gives the noise after a few seconds...)


=== debug output when dropping an *.aac file into playlist ===
amarok: BEGIN: virtual void Playlist::PrettyListView::dropEvent(QDropEvent*)
amarok:   BEGIN: virtual bool Playlist::Model::dropMimeData(const QMimeData*, Qt::DropAction, int, int, const QModelIndex&)
amarok:     [Playlist::Model] this is _something_ with a url....
amarok:     Drop from external source or file browser
amarok:     BEGIN: void Playlist::Controller::insertTracks(int, Meta::TrackList)
amarok:       BEGIN: int Playlist::Controller::insertionTopRowToBottom(int)
amarok:         [Playlist::Controller] SortProxy is NOT SORTED         ... so I'll take care of the right row.
amarok:       END__: int Playlist::Controller::insertionTopRowToBottom(int) [Took: 0s]
amarok:     END__: void Playlist::Controller::insertTracks(int, Meta::TrackList) [Took: 0s]
amarok:   END__: virtual bool Playlist::Model::dropMimeData(const QMimeData*, Qt::DropAction, int, int, const QModelIndex&) [Took: 0.053s]
amarok: END__: virtual void Playlist::PrettyListView::dropEvent(QDropEvent*) [Took: 0.053s]

Thank you for the feedback. If this is a bug it is more likely in sharedmimetypeinfo. Harald?

shared-mime-info actually :P

Considering m4a files work I must assume it is neither a bug in Amarok nor Phonon, as they both recognize audio/mp4 as supported.

So instead something is bogus in the mimetype detection itself.
Surely David Faure will know more :)

>kmimetypefinder foo.mp4
video/mp4

>kmimetypefinder foo.m4a
audio/mp4

This is the issue, shared-mime-info associates *.mp4 with video/mp4.

If it can be audio too, we could also associate it with audio/mp4, but then we need a way to disambiguate the two using the contents of the file. Is there a way to do that, e.g. by looking for specific bytes at a specific offset, or in a small range?

I fear this is not that easy, unless somebody is willing to dive into the ISO specifications of the mpeg4 definition. See also http://en.wikipedia.org/wiki/MPEG-4_Part_14#Filename_extensions

I doubt you will be able to distinguish them all the time.

For reference:
http://www.ftyps.com/

and it doesn't get much more precise than that. mp4 is a rather sophisticated container (much like mkv), so technically it could contain neither audio nor video but pictures arranged in a 3d scene (not that I know of any implementation of that madness) and whether an encoder bothered to use a known ftyp or invent their own is more than questionable. so given it is a container there is no way to do it perfectly right anyway. all you can do is approximate, keep adding new ftyps as they pop up, and pray that people start using apple's m4a/m4v (which of course does not take no-audio-video files into consideration either ;))

*** Bug 267319 has been marked as a duplicate of this bug. ***

Just for completeness sake: the same happens with matroska files with the extension mka. Renaming it to mkv solves the issue.