Bugzilla – Bug 4662
Audio cutoff at beginning of AAC playback
Last modified: 2009-10-05 14:34:43 UTC
I've done major testing and found that when playing an AAC encoded file, and in some cases ALAC encoded as reported by other users, the first 300-350ms of sound is cutoff. It seems the 'delay' is coming from a call to QuickTime(ALAC) prior to encoding by LAME. At first I thought it was a problem with the PQ coding of the CD (I'm in the CD mastering business) but when I opened the image of the disc to confirm the PQ code, it was within the specs of the medium. Not all AAC files do this, and I can't verify what makes some do it and others play normally. Many users on the list have suggested using FLAC to encode as opposed to AAC, but I can't take the time to re-encode the 7000+ songs that I have AAC or ALAC. I have converted the suspect AAC files to MP3 to see if the error follows and it doesn't, as would be expected, since QuickTime is not called prior to LAME. I'm more than happy to help solve this in any way I can. Thanks... BTW, I have tried v7 of the server and the problem still exists.
6.5b3? I'll correct to 6.5.1 on the assumption that you've been trying the nightly builds of that.
recieved via my personal email: "Thanks Deane. You are correct! I don't remember if I had mentioned that I've tried to narrow it down as much as possible. I'm running SS on a 1.8GHz Core Duo Mac MINI w/ 2GB RAM and OS 10.4.8. Everything on there is running Intel Native, at least that's what Activity Monitor is showing. I did have the PPC version of LAME installed, but found v3.97 which is UB, thinking that may change something. It only changed the CPU hits when LAME fires up. Again... please let me know if there's anything I can try or more info I can shoot your way. Thanks for an INCREDIBLE product and the community you share with your users. I've been in the Pro Recording business since 1971 and the relationship SD has with the people that use the product is extremely rare!! DON'T CHANGE!!"
I'm having this issue with some FLAC encoded DTS files, as well. Bit rate is 1500kbps+, but I've got the Transporter hardwired into my network, not wireless. Bandwidth is not a problem.
Could this be another case of the socketwrapper issue? Please try the next nightly build of 6.5.2. Recent updates may help.
*** Bug 5038 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > *** Bug 5038 has been marked as a duplicate of this bug. *** > I don't think this is a duplicate - bug 5038 was related to Slimserver adding a gap before music compared to iTunes. The bug reported by Eric is Slimserver removing 300ms of sound before playing. I think the DTS problem is probably socketwrapper (bug 4544) and not related to this bug which has Quicktime at its core. That said, I think both may be related to iTunes 7 - AAC file which play gapless on Itunes 7, the same AAC files play with gaps on iTunes 6 and slimserver 6.5.x.
i can confirm that i have the same thing happening. mac osx 10.4.9 - not using itunes at all. my library is mixed files of aac, mp3, and flac. all of the aac files miss the first few ms of each track when playing through ss. it has been happening consistently in server versions 6.5.X. currently running 6.5.3, firmware 81.
Steven to try to reproduce
Yes, this is still an issue with SC7. Test files available in bug 5038.
Possible workaround and discussion in bug 4705.
Steven to see if FAAD has any effect on this. There is speculation that gapless playback might be very difficult. Dean notes he would like to consider FAAD for 7.0.
Created attachment 2412 [details] Three recordings of gapless playback. I made three playback recordings of a test suite of 5 second gapless audio files. WAV is the recording of the original wav files. FAAD is using the faad decoder. MOV123 is using the mov123 decoder. I feel FAAD is the way to go even though there are gaps. MOV123 cut out a large portion of the audio. WAV played back without issue.
Those are great recordings, thanks Steven! I agree that the issue is reduced with FAAD, but it is far from 'fixed'. This bug will have to remain open even if we go ahead and switch to FAAD. Setting back to 'unassigned' for review.
One thing I would like to see either way is that AAC has its own transcoding line instead of being grouped with QuickTime, just like we did with ALAC. This would at least make it easier for those that would like to switch over to FAAD in the meantime.
A capital idea! Please file an enhancement request, would you please? :)
I have the same problem with AAC files. I am running the 12/15 build of SC7. Files encoded with AAC have their beggining cut off. Other file formats, including ALAC, don't have this problem.
Forgot to mention I'm running windows.
Dean is this a mov123 bug? How do we get this fixed?
Yes, this appears to be a bug in mov123. The right thing to do would be to move to faad, but this would require a license for AAC, which is expensive, especially since we aren't charging for the software. For folks who are having this problem now, please use the faad workaround. Steven: Is this a windows-only problem?
(In reply to comment #19) > > Steven: Is this a windows-only problem? > If I recall correctly this issue affects all systems that have the ability to use mov123. I just opened bug 8374 requesting a separate file type for AAC to make it easier for those who wish to switch to FAAD for AAC decoding.
There's information on setting up FAAD on our forums at http://forums.slimdevices.com/showthread.php?t=41673
I'm not going to get to look at this for 7.3 so pushing off to 8.0
AAC support has been changed in 7.3.3. Please confirm that this is still a problem with 7.3.3
Alan, I haven't noticed this in quite awhile. I'll check when I get a chance using the last 7.4 nightly, which I've stuck with now that the other issue is solved. I also have 7.3.3 available and had been running it prior to the last 7.4, but really haven't noticed anything funny.
In the absence of any more feedback, I'll mark this as fixed now.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.