m4a playback issues

[zak]

Hi,

My M4As don’t play back properly from mt-daapd. I’ll describe the symptoms as best I can on a per-client basis.

==

On my SoundBridge M1001, selecting an M4A and hitting play results in the screen saying “ – Preparing to play…”. It’ll then sit there for a while, with the lights on the hub showing that it’s busily grabbing data from the mt-daapd server. After a while it’ll start playing (and the lights will keep on twinkling). The length of “a while” seems to be reliable for a given track (I guess it depends on the filesize), but is in the region of 60s for a typical track. MP3s play back fine with 0 – 1s delay. Once the track starts playing, though, it seems to play back OK.

Running Amarok on my laptop and using the fairly new DAAP-as-a-Media-Device hack, browsing to an M4A track and playing it, I get “Connecting to stream source…” briefly, then “Buffering 0%” which zooms up to 100% in about 2s, then Amarok thinks the track is playing. It doesn’t play music though; for about 20s I hear silence occasionally punctuated by squelches and pops (like piping data to a sound device) and then Amarok gives up and declares the track finished. Again, MP3s play back fine with little or no delay.

KDE’s DAAP ioslave can download tracks, and that appears to work, but when I attempt to add the downloaded file to a playlist in Amarok it eats prodigious amounts of RAM and crashes out (not mt-daapd’s problem, of course). The downloaded file is a little longer than the original (is this to be expected?). If I play the original track in Amarok over Samba instead of DAAP it works fine.

iTunes on a PC does nothing when I double click on the shared M4A tracks; it just sits there at 0:00, with a speaker symbol next to the track in the playlist, but without the “sound lines” coming out. When I double-click an MP3 it plays fine, and I get a speaker symbol with “sound lines”, and an exclamation mark appears next to the M4A track. If I add the original track to the local iTunes library on the PC it plays back just fine.

==

I’d like to have tried sharing the same M4A tracks from iTunes 6 to Amarok, the ioslave, the SoundBridge and maybe another iTunes 6, as I think this’d help massively in nailing the problem down, but all the PCs at my disposal are already running iTunes 7 and none of my clients have the required DAAP hack yet.

All this is 100% reproducible. I’ve not tested with a wide range of my M4A tracks because it’s clearly time-consuming, but I think the same problem occurs with all of them. It’s probably worth mentioning that AFAIK the tags on these M4As have all been edited with the same tagging tool – EasyTag. Given that tracks downloaded with KDE’s DAAP ioslave can’t even be added to an Amarok playlist without things going wrong, I’m wondering if maybe the tags or file structure are getting screwed up somehow when being served over DAAP, and all the clients are basically doing the same thing – scanning the entire stream for a tag due to some inconsistency, forcing them to download the whole thing, and then failing in their various ways when they come to try and play the messed up result. Just a theory.

I’ve had this problem with every version mt-daapd I’ve used (0.2.4, 1281 and 1376). I’ve finally got around to asking for help because other people have started using my SoundBridge and pestering me about how M4As (a minority format in my mostly MP3 collection) don’t play back; before now I’ve been happy to listen to those few tracks on my iPod or on my laptop.

I’m using a fairly standard mt-daapd setup (not that there’s huge scope for fancy configs AFAICS). No SSC or anything for M4As. I’m running nightly 1376 on little-endian ARM Debian on a NSLU2. My config file follows.

Any ideas where to go next?

Cheers in advance,

Zak

==== begin mt-daapd.conf ====
[general]
web_root = /usr/local/share/mt-daapd/admin-root
port = 3689
admin_pw = letmein
db_type = sqlite3
db_parms = /var/cache/mt-daapd
mp3_dir = /mnt/big/share/music/music
servername = Zak’s Music
runas = nobody
playlist = /etc/mt-daapd.playlist
extensions = .mp3,.m4a,.ogg
ssc_codectypes = ogg
ssc_prog = /usr/local/bin/mt-daapd-ssc.sh
logfile = /var/log/mt-daapd.log
rescan_interval = 3600
scan_type = 2
[plugins]
plugin_dir = /usr/local/share/mt-daapd/plugins
plugins = rsp.so,ssc-script.so
==== end mt-daapd.conf ====

[zak]

Managed to get a copy of iTunes 6[1] installed to serve the same file. If I download a given track from mt-daapd and iTunes 6, their MD5s match, so mt-daapd is behaving exactly like iTunes 6 here.

In keeping with the “be liberal about what you accept, and conservative about what you produce” school of thought, it’d be nice if mt-daapd could be better than iTunes in this respect, and either refuse to serve a file with messed-up tags or, even better, serve a version that’ll play by sanitising the data.

Anyway, I guess the problem is the contents of the AAC file, but as both iTunes and Amarok play the files just fine from the local library, I’m at a bit of a loss as to why streaming it would break stuff. So the next question is: How/why does the served stream differ from the original file? (Streams are different for served MP3s too, not just AAC.) I’m sure I could work this out by spending enough time doing diffs or digging through sources, but if someone could give me a headstart that’d be great 🙂

[1] A quick visit to http://www.apple.com/support/downloads/ reveals that iTunes 6 is really popular ever since 7 came out 🙂

[zak]

As if the MD5 wasn’t proof enough of mt-daapd’s innocence, from looking at the source and at an ethereal capture of the exchange when I play a track with Amarok it appears that mt-daapd just sends the file down the pipe, only altering it if you’ve turned on dynamic addition of cover art, which I haven’t. So both mt-daapd and iTunes are serving exactly what’s on the disk, no more, no less, and the data itself must be at fault.

I still don’t understand quite how all three clients fail to stream these tracks regardless of the fact that they load and play fine locally in iTunes, Amarok and on my iPod – but with mt-daapd in the clear, I guess that’s my problem. I know this isn’t really the forum for discussing non-mt-daapd issues, but if anyone happens to have had any experience with this I’d appreciate any advice 🙂

[zak]

The answer, which I eventually stumbled on at:
http://www.rokulabs.com/support/sbtroubleshooting.php#Playback
is that M4As to be streamed over DAAP need to be “fast-start” compatible. A tool called mp4creator exists for Windows, Linux and OS X that can make the necessary change to an M4A file.

The not-particularly-complicated nuts and bolts of this: clients streaming a track over DAAP need info that encoders sometimes only put at the end of the track. If it’s only at the end, some poorer clients (iTunes, Amarok) just won’t play it, while better ones (SoundBridge) will buffer the whole track looking for the info and eventually find it. If there’s a copy of the info at the beginning, it seems to work with any client. “mp4creator -optimize” ensures there’s a copy at the beginning of the track. If the file is local (iPod, Amarok lib, iTunes lib) then the player can just seek to the end, so the copy at the start isn’t required (but doesn’t hurt).

I hope this saves someone some time 🙂

[rpedde]

@zak wrote:

The answer, which I eventually stumbled on

lol… sorry, you are too quick for me. Yes, it’s the metadata order thing. Had I checked in here earlier, I would have saved you the time searching.

Sorry about that. :/

— Ron

p.s. glad you got it working though.

[jtbse]

Just additional fyi….

I’ve recently discovered that besides the command-line mpeg4ip utilities mentioned in the Roku FAQ, Windows users can use MP3Tag to optimize their .m4a files with a GUI.

A bit easier to work with after the fact, but I still prefer the CLI since I can add it as a post-conversion task when converting to .m4a with dbPowerAmp.

[Author]

Posts