@schro20 wrote:
What does the “offset” field in the server logs indicate? As I mentioned, the first serve serves to ipnumber:offset 0 while the second one (which I can hear) serves to ipnumber:offset 32. Perhaps there is a hint in that behavior.
Stretch is exactly right — the file you have isn’t fast-start enabled.
Basically, it works like this — there is a ton of data in a m4a file — album and author info, info about bitrate and sample size, album art, lyrics, etc.
They all get laid out in the file one block after another in any order.
So you can lay out the data in the file however you want, but there is a smart way to do it and a dumb way. The smart way is to put the data you need to play the music (sample rate, etc) at the start of the data, then the actual music data after it. That way, if the song is streamed, you get the chance to read the info you need to play the music before you see the music.
The dumb way, on the other hand, puts the metadata *after* the actual music data. In the case of a file played on the local PC, it doesn’t matter. You can skip to the end of the file, read the metadata you need, then skip back to the beginning of the file. That works fine.
When you stream, though, it sucks… you can’t really seek to the end of a file, you have to stream the whole file to get there.
That’s what’s happening here. It has to stream the whole file to get the metainfo it needs to play the song, and then has to restart the stream in order to actually play the music data, which is sitting at the beginning of the file (offset 32).
So that’s what the mpeg4ip utility does — it rearranges the data so it’s got the metadata first.
— Ron