Bugzilla – Bug 2095
Gap between songs with the Apple lossless (ALAC) files
Last modified: 2008-09-15 14:39:24 UTC
I hear gaps between songs when I play SB2 with the Apple lossless files. I hear the gaps with both analogue and digital outputs. The crossfade is set to none. Also, when I swiched to use the Apple lossless to the WAV file conversion (in the file format) instead of the Apple lossless to flac conversion I hear loud popping noise and/or the gap.
Hiroyuki: How long is the gap, in seconds?
It's very, very short. Also, it sounds like the beginning of the next song sounds slightly cut off, perhaps. It's making the seam between the songs apparent in continuous live recordings and etc.
Ok, thanks for the additional information. We'll have to address this after 6.2 is finished.
I'm also seeing this problem. I sent the following email to Kevin Pearsall: "I have a Squeezebox 2, and I'm running Slimserver 6.0.2 on an Apple Powerbook (Mac OS X 10.3.9). My music is encoded as Apple Lossless and is transcoded to flac for playback on the SB2. I am finding that the first half second or so of (I believe) every track is missing. This is especially noticeable when the CD tracks are continuous (i.e. gapless) - it sounds like a short skip. After some experimentation I've tried dropping in an alac binary (http://craz.net/programs/itunes/alac.html) and using that to decode the lossless files before piping them to flac (all done by modifying convert.conf). This removes the gap, although it introduces other problems (occasional stuttering) so it's not ideal - probably because alac is in a relatively early stage of development. So the problem seems to be with mov123. Do you know of any problems with this? Could it be related to Quicktime 7? I have also tried the same thing on a Mac OS X 10.4.1 machine and I get the problem. What do you suggest I do?"
this came up again, we need to fix this issue... i sent him the following workaround and compiled alac for him. raising priority of this issue. To replace mov123 as your ALAC decoder on OSX 10.4.4, we need to do two things. First you need to drop the alac binary which I have attached in to home -> Library -> SlimDevices -> bin, then you need to modify a file called convert.conf. I actually found that we already have directions for modifying convert.conf up on our wiki. But basically on a Mac you would want to: - open a new finder window - go to home -> library -> preferencepanes - ctrl-click on slimserver.prefpane and click show package contents - open up contents - open up server - ctrl-click on convert.conf and click open with, and open it with textedit... - make the modifications mentioned on this page: http://wiki.slimdevices.com/index.cgi?AppleLosslessUnix - restart SlimServer and try again (I think this may break playback of AAC files, though... But I'm not sure...) Regards, Kevin P.
I have another customer experiencing this issue. I'll ask him to drop some notes in the bug, as there isn't much else I can do here since he's on Windows...
Having yet another customer experiencing this issue. Can we look at this?
I've been suffering from these pops between songs for a while too, isolated the issue to the handling of Apple Lossless. Configuration: OX 10.4.5, Mac Mini 1.25 GHz w/ 1 GB ram, Slimserver 6.2.1, Squeezebox 1. During playback the first msecs of each song are skipped. Not sure how many msecs, but it's a clearly audible pop. The music library is stored in Apple Lossless. The files are fine, I checked that earlier by burning them back to disk and importing a whole CD as one AIFF file, which played ok. Also tried Softsqueeze instead of the Squeezebox: same problem with the gaps, so it's not the music hardware. Converted an album to Flac, and tried again. Everything plays fine in this case, no gaps. So it seems to be related to Slimservers handling of Apple Lossless files. Also, I *think* there's more disk activity when starting a new Apple Lossless song, as compared to a flac one. Perhaps it has to do with buffering?
This is easily reproducible on my test mac. I'd estimate easily on my system almost half a second is missing from the beginning of each ALAC playback.
I believe I'm the customer Kevin refers to in comment #6. This has been a very real problem on my Windows XP machine. Most tracks are ok, but tracks that start with very little lead time get clipped, and songs that span multiple tracks produce a clear audible skip. Since this only affects a handful of tracks, I found that an effective workaround was to convert these specific tracks to AIFF format. This takes up a bit more room on the HD, but retains full compatibility with iTunes. Although this works, my final solution was to build a Linux server so that I could use ALAC to do the decoding. I'm not sure if ALAC could be used on Windows. Whereas it compiles easily on Linux, a quick stab at compiling it on Windows was unsuccessful.
Just wanted to add my experience, which is that I'm also seeing this same bug. Just as with comment #4 and comment #8, the first 100-250 milliseconds of songs are cut off (always at the beginning of tracks). Most tracks include a small silence buffer at the beginning, so this bug is not audible on those tracks. On tracks where there is no such silence buffer (abruptly-starting tracks and tracks intended for gapless playback, e.g. DJ mixes), this bug is quite audible and rather annoying. I'm using SlimServer 6.2.2 on OS X 10.3.9. All of my files are in Apple Lossless and are server-side transcoded to FLAC before sending to the Squeezebox. The files themselves are perfectly OK, verified by playing in iTunes and conversion to AIFF. There have been a number of threads on this topic in the forums. Some reports on the forums suggest that turning ALAC->FLAC conversion OFF (and using ALAC->AIFF instead) is a workaround, suggesting that this bug may be related to bug #1434. However, other reports say this bug still exists even with ALAC->AIFF, suggesting that the bug is due to mov123 and NOT due to the FLAC bug #1434. It's also possible that BOTH bugs are contributing to this issue (in the case of ALAC->FLAC transcoding). Either way, it seems this bug is rather widespread for ALAC users. Many may not notice it if they don't listen carefully or (probably the more common case) all of their tracks include a silence buffer in the beginning. However, the number of reports on this bug indicate that it is real, and that people who notice it find it rather annoying... I'd be happy to bug-test any new software, just let me know.
I've got this issue as well. Let's see a fix! A really annoying problem. My whole library is ripped in Apple lossless and I'd say about 10% of it is affected by this.
Almost all my music (over 3000 albums) is ripped as either AAC or Apple Lossless, and this bug is audibly trimming around one in ten tracks. Streaming as AIFF doesn't make any difference unfortunately, and ripping to AIFF is not a viable option at the moment - I have neither the storage nor time. I can only presume that the problem resides in the use of the mov123 decoder. I must admit that I haven't tried the ALAC fix in Comment #5. The possibility of breaking AAC playback rather put me off. Obviously I'd love to see this bug fixed. It's the one and only niggle that I've had with my SB3.
Chris, could you test this please. I think this problem is resolved in slimserver 6.3 / firmware 55 as it is probably releated to bug 3303.
Richard, Why do you say this is probably related to bug 3303? That bug seems to be FLAC-related. This bug seems to be related to mov123, on the other hand - most of the posters here and on the forums say that using ALAC->AIFF transcoding (instead of ALAC->FLAC) doesn't fix the problem. That suggests that mov123 is the culprit rather than the FLAC conversion. Just wondering why you suspect it's related to bug 3303, then - is that bug more fundamental, rather than directly related to FLAC?
I'm running Slimserver 6.3, Firmware 55. The bug is definitely still present when playing AAC files, both when converted to AIFF or FLAC. As far as I can see it is not related directly to bug 3303, or at least not to the ALAC playback problems that people were having.
Sorry, that last line was supposed to say "the FLAC playback problems that people were having." Long day, not enough sleep. ;)
Actually what I'm hearing is actually there's too LITTLE gap. That is, a brief piece of the music (approx 2/3 sec) is missing. Regardless, something is broken there. I tested with the 6.3 official release from yesterday, on osx 10.4. I'll attach some example files in a sec.
(In reply to comment #18) > Actually what I'm hearing is actually there's too LITTLE gap. Chris: that's exactly what I'm hearing, as posted in comment #11. Others on the forum have posted similar experiences. It appears that something is getting clipped, as if mov123 is just ignoring the first few KB of the song.
Created attachment 1292 [details] 1/2 .m4a file displaying ALAC gap
Created attachment 1293 [details] 2/2 .m4a file displaying ALAC gap
Out of curiosity I tried some AAC files on a Windows install of Slimserver 6.3. Exactly the same clipping occurs under Windows as under OS X. I've been using some of my own music, which I know has a very abrupt start (rendering notes immediately in the sequencer), as a test. I can post example mp3 and m4a files if it would help.
Assigning to Dean since he's the maestro of apple formats.
Also possibly affects some WMA lossless formats? Kevin has filed a separate bug on that. He speculates that this has something to do with server machine speed as well.
Chris, I don't know about WMA lossless, haven't tried those. As for server machine speed, I highly doubt it. I realize my server is really old and slow by today's standards (dual-500MHz G4), but the mov123 and flac processes both take up less than 10% CPU when running. This particular bug is so consistently repeatable, and the transcoding processes take up so little CPU, that I don't see how server speed can be a factor here. Perhaps if this were running on a 233MHz G3, maybe, but in my case the CPU does not appear to be the bottleneck.
G5 iMac here. Barely registers any CPU load when processing. Exactly the same problem when I run Slimserver on an XP machine with an Athlon 2.8 in it, so I very much doubt it's a CPU bottleneck at the root of this.
*** Bug 2985 has been marked as a duplicate of this bug. ***
Chris, It has been hypothesized by some that this bug is related to the mov123 executable. The evidence supporting this is that people using the 'alac' executable instead of mov123 have reported that it solves the clipping issue. If mov123 is the culprit, it should not affect WMA Lossless. Do you think the bug is somewhere outside of mov123, in which case it could affect WMA, or do you think the two bugs are related but different?
Looking into an alternate ALAC decoder for post 6.5
Dan will be looking at the ALAC port.
Change 9103 adds server support for the alac 0.1.1 binary & automatic conversion of Apple Lossless files. Please let me know if that fixes these issues. Thanks
Dan, Previous comments (see comment #4 and comment #5) have indicated that the alac binary introduces other problems, e.g. stuttering and/or breaking AAC playback. Have these been tested with change 9103? Also, people claim that this bug also affects AAC (e.g. comment #16) and possibly AIFF. Using the alac binary may fix this issue for ALAC transcoding, but mov123 is still used for AAC and AIFF, so what will be done to fix this bug for those formats (specifically AAC)?
Judging from the date, the posters used the 0.1.0 version of alac. I've commited the 0.1.1 version of alac, which has a number of fixes. AIFF is just passed through to the players (unless you have a SliMP3). Nothing has been done regarding AAC. I would recommend updating to the latest version of QuickTime. Beyond that, the 'mov123' binary is just a simple wrapper around the QuickTime decoders.
Dan, I realize mov123 is just a wrapper, but clearly it has a bug somehow... one would think that a wrapper couldn't have a bug and that the bug must therefore be in the underlying libraries. However, this can't be the case because iTunes does not exhibit this skipping bug and mov123 does. There is clearly something different about how mov123 interacts with QT than, say, iTunes. As another example, I cannot play ALAC files on the Squeezebox using QT 6.5 (and mov123), yet iTunes plays those files just fine with QT 6.5. So, although mov123 is just a wrapper, it's doing something different than what iTunes and other Apple apps do... Thanks!
Ok - I'm going to close this bug. Please open a new bug regarding gapless playback with AAC files. Thanks
Dan, My concern isn't really with AAC, since I use ALAC anyway (see comment #11). I was trying to be a voice for others, is all. =) But I am still wondering why this bug appears to be within mov123, which really is just a wrapper... what is the difference between how mov123 and iTunes access ALAC files? That difference may be the clue to this bug. (Using alac may be a workaround but I'm curious how this bug can occur in the first place, given the simple nature of mov123.)