Short delay when playing ALAC files

[cepheid]

I'm in the process of ripping my CDs to Apple Lossless (ALAC), and noticed what may be a bug in the server. Specifically, there appears to be a short (perhaps 0.1 to 0.25 second) delay at the beginning of songs.

By and large, most tracks have some blank space at the beginning so this isn't an issue, but some tracks on some CDs (including some rock CDs, but most notably electronica CDs where tracks often have no gaps) don't have this empty space and the music starts right away. In these cases, the SB ends up chopping off a bit of the beginning (as mentioned, perhaps a tenth to a quarter of a second). If anyone has Catherine Wheel's "Happy Days," you can verify this with tracks 10 and 11, for example.

This happens even if the SB is just playing the tracks straight through, i.e. I'm not touching the remote and shuffle is OFF, so (in principle) it's like playing the CD.

I suspect this is due to buffering on the server side as the server transcodes the ALAC to FLAC before sending it to the player... but there's no reason it should be chopping off ANY of the music, since it should simply introduce a small delay rather than actually delete bits.

Note that I've checked the music files locally on the computer - they play just fine. It's only through the SB that the initial few moments get chopped.

This is using SlimServer v6.2.2 (nightly from 04/07 I believe, though I'm not certain), OS X 10.3.9, with QT 7.0.4.

Anyone else experiencing this?

[Chris OH]

Hi,

Not sure this is a problem with Slimserver or not. Is gapless playback possible yet with ALAC ? I dont think so, which is why I use FLAC and have an i audio X5 rather than an ipod as it can play FLAC gapless as well. It is surprising how anoying the gaps become if you are sensitive to them.

Chris

[radish]

Apple have a long history of not caring about gapless playback (see: ipod/itunes etc). I don't know for certain whether ALAC supports it but I'd always assumed not for that reason. What I do know is that using the appropriate formats (PCM, FLAC, Vorbis, etc) the squeezebox is perfectly gapless.

One thing worth trying would be to stream as PCM instead of FLAC, but I'd be a little surprised if that fixed it.

[MartinP]

I have files ripped to ALAC, decoded to FLAC before streaming to the SB, and they play gaplessly. Are you using an external DAC? Sometimes they take a fraction of a second to begin decoding - I have this problem using digital out from my CD player to my amp.

[radish]

Another thing which comes to mind - make 100% sure you're not streaming as mp3 without realising it - mp3 streamed files are not gapless on SB.

[cepheid]

MartinP, I am not using an external DAC... I'm feeding the SB from the server and taking the analog output to the receiver. So in principle it should all be working as advertised. The SB is connected wirelessly, but again that shouldn't be an issue because I'm not getting any dropouts at ANY other time.

radish, I definitely made sure it's not transcoding to mp3. In fact, I don't even have lame installed so it CAN'T transcode to mp3. =)

My main concern is NOT the lack of gapless playback, but rather than a heartbeat gets *skipped*... I can most certainly hear the lack of maybe a tenth or a quarter of a second of music (basically the first beat). If there were a pause, that'd be one thing, but this is actually skipped bits!

[Wombat]

Flac gapless simply not works until now on the Squeezebox. ALAC->flac from the server can´t be better then.
The only thing that may work is ALAC->wav on the server.
This is known and an official bug.

[radish]

My main concern is NOT the lack of gapless playback, but rather than a heartbeat gets *skipped*... I can most certainly hear the lack of maybe a tenth or a quarter of a second of music (basically the first beat). If there were a pause, that'd be one thing, but this is actually skipped bits!

Oh - I'm sorry I thought you were talking about gaps, I misread your original post. If what you're hearing is a gapless transition but with a tiny bit missing, then yes, this is a known issue. The bug report (which I raised, as it happens), is here : http://bugs.slimdevices.com/show_bug.cgi?id=1434

Please feel free to vote on it, I'm hoping to get it to the top of the queue In the meantime, disabling FLAC streaming and using PCM instead should work - it does for most (all?) people with this problem.

[Wombat]

btw. This bug is going to get on my nerves. This isn´t a seldom phenomena at all. If you have the "Batman Returns OST" listen to the gap between song 1 and 2. The resulting click is much louder than the music itself. Tobular Bells 2 also is annoying.
I hope it is possible to fix this at all. Cause something like this is a kind of ko criteria to me.

[cepheid]

If what you're hearing is a gapless transition but with a tiny bit missing, then yes, this is a known issue.

This seems to be similar but not identical to my experience. Your bug report says that the end of the track is cut off, whereas in my experience, it's the beginning of the track. I guess it's possible (since you were listening to gapless files) that you attributed the skip to the end of the first track rather than the beginning of the second... but if not (i.e. if you're sure it skipped the end, not the beginning) then this may be a related but separate bug.

I first noticed this not on gapless tracks but rather plain rock tracks, specifically while listening to Catherine Wheel's Happy Days album. Tracks 10 and 11, for example, are recorded such that the songs start literally at the very beginning of the track, without the usual silence buffer. However, the end of the previous tracks DO have silence, so the fact that the missing bit is from the beginning of the tracks is very evident.

Hopefully this makes sense. Do you think your skipped pieces (per your bug report) are actually at the beginning of track 2 rather than the end of track 1? If so, I can add my comments to your bug; otherwise this may be a different bug and worth submitting separately.

I will try disabling ALAC->FLAC streaming and using just ALAC->WAV ... we'll see whether that helps or not. Hopefully I've got enough bandwidth to send WAV through the wireless network.