streaming alac to roku

Discuss the current and future development of Max.
Post Reply
gordo
Posts: 9
Joined: Mon Dec 25, 2006 2:20 am

streaming alac to roku

Post by gordo » Fri Jan 05, 2007 1:00 am

The Roku soundbridge now supports apple lossless so I'm considering changing my flac to alac for better compatibility with itunes/ipods etc. Unfortunately files transcoded to m4a alac using max don't work. At first I though t it might be related to the fast start issue regarding tag info at the beginning of the file but that shouldn't be an issue with recent versions of max and the files stream just fine to an itunes client. Roku response is listed below. Is this something that can be fixed in max? The alac command line decodes the file fine so I don't think it is a purely alac problem, seems to have something to do with streaming and tagging. At least adding bitrate info should be easy, not sure about the other

Thanks

Thom

_________

Hi Thom,

I found two problems.

1) However this file is encoded, iTunes is reporting the bitrate as "unknown". Without the bitrate, we can't determine that it's an ALAC file, so we try to play it as AAC, and fail.

2) I forced our code to treat the file as ALAC, and I then saw a failure in processing the 'hdlr' chunk inside the 'mdia' chunk. It looks like it's missing some expected elements, so that as data is read we end up reading data as a size or vice-versa, and this causes a later failure.

For what it's worth, we do seem to be using the latest (0.1.3) ALAC code.

I'm not able to spend time on this now until after CES, but I'll try looking at it again then. In the meantime, perhaps you'd be interested in contacting David Hammerton (the ALAC codec author) and letting him have a look at your file?

Best,
--Mike

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Sat Jan 06, 2007 1:09 am

Could this be related to the slimserver issue?

Also, do you know which chunk roku uses to read the bitrate?

gordo
Posts: 9
Joined: Mon Dec 25, 2006 2:20 am

Post by gordo » Sat Jan 06, 2007 10:57 pm

Initially I thought it was the slimserver issue but Roku is using the most recent version of alac (0.1.3) which I understood fixed that.

One thing I noticed with max produced alac files is that when I play them using audacious on my linux server it complains about not valid utf-8 and only shows the album name - not song name - for now playing. Not sure if it's related but does suggest some tagging difficulty.

One new data point is the files decode to wav just fine using the command line version of alac.

i am pretty sure it is tag related since if I encode using itunes it works but then changing the tag in the file with just about anything causes it to stop.

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

More info

Post by sbooth » Tue Feb 13, 2007 11:11 pm

Here is a copy of an e-mail I sent that relates to this issue. More questions than answers, I'm afraid.
I've been having great difficulty getting Core Audio generated MPEG-4 Audio (Apple Lossless) files to work properly in iTunes. I know it's been mentioned on here before, but I wanted to ask something similar yet different.

The issue is that alac files generated by Core Audio do not show up as having a bitrate in iTunes. This is easily verifiable by taking a WAV file and using the afconvert tool to create an Apple Lossless file:

afconvert -f 'm4af' -d 'alac' input.wav output.m4a

output.m4a, when imported into iTunes, does not show up as having a bitrate.

I did some experimentation by creating a single-channel, single-sample WAV file and creating an alac file from it using Core Audio and iTunes. The 'mdhd' and 'stsz' atoms were identical, but the 'stsd' atoms were not. Here are the two atoms for reference:

iTunes-generated m4a file:

size = 00000058 (88)
type = 'stsd' (Sample Description)
version = 00
flags = 000000
number of entries = 00000001
sample desc size = 00000048 (72)
data format = 'alac'
reserved = 000000
data reference = 00

00000001 (entry count)
00000000 00000000 (reserved)
0001 (channels)
0010 (sample size)
0000 (pre_defined- compression id?)
0000 (reserved- packet size?)
AC44 (sample rate)
00000000 0024616C
61630000 00000000
10000010 280A0E01
00FF0000 000A0000 <--
035D0000 AC44 <--


I've placed some educated guesses as to the codec-specific data (magic cookie) in parentheses. (Data fields according to ISO/IEC 14496-12:2005(E)).

Core Audio-generated m4a file:

size = 00000058 (88)
type = 'stsd' (Sample Description)
version = 00
flags = 000000
number of entries = 00000001
sample desc size = 00000048 (72)
data format = 'alac'
reserved = 000000
data reference = 00

00000001 (entry count)
00000000 00000000 (reserved)
0002 (channel count !!)
0010 (sample size)
0000 (pre_defined)
0000 (reserved)
AC44 (sample_rate)
00000000 0024616C
61630000 00000000
10000010 280A0E01
00FF0000 50010000 <--
00000000 AC44 <--

Interestingly, the file shows up as having two channels! The weird thing is, when opening the file in iTunes or QuickTime Player it is reported as mono. What have I missed in this analysis?

Finally, it's obvious the final two bytes are the sample rate (44100 in this case). So, the 16 bytes before the final 2-byte sample rate are different between the two. Could this be causing the issue? Is this where iTunes stores the bitrate?

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests