Bugzilla – Bug 3610
Music skips when changing tracks whilst using CUE file
Last modified: 2010-04-14 19:22:17 UTC
When playing large MP3 files that have their track information encoded within a CUE file the music will momentarily skip as the player switches to displaying the track information for the new track. The skipping sounds to be the result of the player resynchronising the sound and playing the new track a fraction of a second ahead of when it should start. The fault seems to appear when using both version 6.2.2 and the 6.3.0 nightly build.
chris/ross to reproduce
SlimServer Version: 6.3.0 - 7987 - Windows XP - EN - cp1252 I wasn't able to reproduce this. I ripped a CD to MP3 with a cue file via EAC. Moved them to my music folder and rescanned within slim server. Clicked play, no delay, no skip, sounds fine. Andi could you provide me with any more detail that might help? How are you creating your mp3/cue files, what software are you using and what specific settings? Could you describe this momentary skipping, how brief is it? Is it only at the beginning of the song, or for the duration? I'm listening/watching very closesly and not noticing. You don't notice this with any other file format right?
Subject: Re: Music skips when changing tracks whilst using CUE file Hi Ross The files that I am playing have also been ripped using EAC using the LAME encoder set to 320 bps VBR. The 'skipping' or glitch occurs once each time the the player switches from one track to the next and sounds as if the beat of the music is ever so slighly out of time for just one beat only(less than half a second I would say). Its as if the player starts playing the next track a fraction of a second early, even though the file being played is a continuous MP3 file. I haven't tried any other file formats as all my music is encoded as VBR MP3. I'm not at home right now, but when I get home tomorrow, I will try ripping a CD to some different formats to see if the problem persists. Andi On 21/06/06, Slim Devices Bugzilla <bugs@bugs.slimdevices.com> wrote: > > https://bugs-archive.lyrion.org/show_bug.cgi?id=3610 > > > ross@slimdevices.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |ross@slimdevices.com > > > > > ------- Comment #2 from ross@slimdevices.com 2006-06-20 17:43 ------- > SlimServer Version: 6.3.0 - 7987 - Windows XP - EN - cp1252 > > I wasn't able to reproduce this. I ripped a CD to MP3 with a cue file via > EAC. > Moved them to my music folder and rescanned within slim server. Clicked > play, > no delay, no skip, sounds fine. > > Andi could you provide me with any more detail that might help? How are > you > creating your mp3/cue files, what software are you using and what specific > settings? Could you describe this momentary skipping, how brief is it? Is > it > only at the beginning of the song, or for the duration? I'm > listening/watching > very closesly and not noticing. You don't notice this with any other file > format right? > > > > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. > Hi Ross<br><br>The files that I am playing have also been ripped using EAC using the LAME encoder set to 320 bps VBR. The 'skipping' or glitch occurs once each time the the player switches from one track to the next and sounds as if the beat of the music is ever so slighly out of time for just one beat only(less than half a second I would say). Its as if the player starts playing the next track a fraction of a second early, even though the file being played is a continuous MP3 file. I haven't tried any other file formats as all my music is encoded as VBR MP3. <br><br>I'm not at home right now, but when I get home tomorrow, I will try ripping a CD to some different formats to see if the problem persists.<br><br>Andi<br><br><div><span class="gmail_quote">On 21/06/06, <b class="gmail_sendername"> Slim Devices Bugzilla</b> <<a href="mailto:bugs@bugs.slimdevices.com">bugs@bugs.slimdevices.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href="https://bugs-archive.lyrion.org/show_bug.cgi?id=3610">https://bugs-archive.lyrion.org/show_bug.cgi?id=3610</a><br><br><br><a href="mailto:ross@slimdevices.com">ross@slimdevices.com</a> changed:<br><br> What |Removed |Added <br>----------------------------------------------------------------------------<br> CC| |ross@<a href="http://slimdevices.com">slimdevices.com</a><br><br><br><br><br>------- Comment #2 from <a href="mailto:ross@slimdevices.com">ross@slimdevices.com</a> 2006-06-20 17:43 -------<br>SlimServer Version: 6.3.0 - 7987 - Windows XP - EN - cp1252<br><br>I wasn't able to reproduce this. I ripped a CD to MP3 with a cue file via EAC. <br>Moved them to my music folder and rescanned within slim server. Clicked play,<br>no delay, no skip, sounds fine.<br><br>Andi could you provide me with any more detail that might help? How are you<br>creating your mp3/cue files, what software are you using and what specific <br>settings? Could you describe this momentary skipping, how brief is it? Is it<br>only at the beginning of the song, or for the duration? I'm listening/watching<br>very closesly and not noticing. You don't notice this with any other file <br>format right?<br><br><br><br><br>------- You are receiving this mail because: -------<br>You are on the CC list for the bug, or are watching someone who is.<br>You reported the bug, or are watching the reporter.<br></blockquote> </div><br>
Subject: Re: Music skips when changing tracks whilst using CUE file Ross, I've tried ripping a CD into both variable bit rate and constant bit rate MP3 files and found that the glitches are non-existant/not noticable when playing the CBR file.. However the playback skips at every track change when playing the VBR file. Let me know if you require anymore information. Andi On 21/06/06, Andi Strain <andi.strain@gmail.com> wrote: > > Hi Ross > > The files that I am playing have also been ripped using EAC using the LAME > encoder set to 320 bps VBR. The 'skipping' or glitch occurs once each time > the the player switches from one track to the next and sounds as if the beat > of the music is ever so slighly out of time for just one beat only(less than > half a second I would say). Its as if the player starts playing the next > track a fraction of a second early, even though the file being played is a > continuous MP3 file. I haven't tried any other file formats as all my music > is encoded as VBR MP3. > > I'm not at home right now, but when I get home tomorrow, I will try > ripping a CD to some different formats to see if the problem persists. > > Andi > > > On 21/06/06, Slim Devices Bugzilla <bugs@bugs.slimdevices.com> wrote: > > > > https://bugs-archive.lyrion.org/show_bug.cgi?id=3610 > > > > > > ross@slimdevices.com changed: > > > > What |Removed |Added > > > > ---------------------------------------------------------------------------- > > CC| |ross@slimdevices.com > > > > > > > > > > ------- Comment #2 from ross@slimdevices.com 2006-06-20 17:43 ------- > > SlimServer Version: 6.3.0 - 7987 - Windows XP - EN - cp1252 > > > > I wasn't able to reproduce this. I ripped a CD to MP3 with a cue file > > via EAC. > > Moved them to my music folder and rescanned within slim server. Clicked > > play, > > no delay, no skip, sounds fine. > > > > Andi could you provide me with any more detail that might help? How are > > you > > creating your mp3/cue files, what software are you using and what > > specific > > settings? Could you describe this momentary skipping, how brief is it? > > Is it > > only at the beginning of the song, or for the duration? I'm > > listening/watching > > very closesly and not noticing. You don't notice this with any other > > file > > format right? > > > > > > > > > > ------- You are receiving this mail because: ------- > > You are on the CC list for the bug, or are watching someone who is. > > You reported the bug, or are watching the reporter. > > > > Ross,<br> <br> I've tried ripping a CD into both variable bit rate and constant bit rate MP3 files and found that the glitches are non-existant/not noticable when playing the CBR file.. However the playback skips at every track change when playing the VBR file. Let me know if you require anymore information.<br> <br> Andi<br><br><div><span class="gmail_quote">On 21/06/06, <b class="gmail_sendername">Andi Strain</b> <<a href="mailto:andi.strain@gmail.com">andi.strain@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div>Hi Ross<br><br>The files that I am playing have also been ripped using EAC using the LAME encoder set to 320 bps VBR. The 'skipping' or glitch occurs once each time the the player switches from one track to the next and sounds as if the beat of the music is ever so slighly out of time for just one beat only(less than half a second I would say). Its as if the player starts playing the next track a fraction of a second early, even though the file being played is a continuous MP3 file. I haven't tried any other file formats as all my music is encoded as VBR MP3. <br><br>I'm not at home right now, but when I get home tomorrow, I will try ripping a CD to some different formats to see if the problem persists.<br></div><div><span class="sg"><br>Andi</span></div><div><span class="e" id="q_10bf6a9d2eb54c18_2"><br><br><div><span class="gmail_quote">On 21/06/06, <b class="gmail_sendername"> Slim Devices Bugzilla</b> <<a href="mailto:bugs@bugs.slimdevices.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">bugs@bugs.slimdevices.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href="https://bugs-archive.lyrion.org/show_bug.cgi?id=3610" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://bugs-archive.lyrion.org/show_bug.cgi?id=3610</a><br><br><br><a href="mailto:ross@slimdevices.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> ross@slimdevices.com</a> changed:<br><br> What |Removed |Added <br>----------------------------------------------------------------------------<br> CC| |ross@<a href="http://slimdevices.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">slimdevices.com</a><br><br><br><br><br>------- Comment #2 from <a href="mailto:ross@slimdevices.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ross@slimdevices.com</a> 2006-06-20 17:43 -------<br>SlimServer Version: 6.3.0 - 7987 - Windows XP - EN - cp1252 <br><br>I wasn't able to reproduce this. I ripped a CD to MP3 with a cue file via EAC. <br>Moved them to my music folder and rescanned within slim server. Clicked play,<br>no delay, no skip, sounds fine.<br><br>Andi could you provide me with any more detail that might help? How are you<br>creating your mp3/cue files, what software are you using and what specific <br>settings? Could you describe this momentary skipping, how brief is it? Is it<br>only at the beginning of the song, or for the duration? I'm listening/watching<br>very closesly and not noticing. You don't notice this with any other file <br>format right?<br><br><br><br><br>------- You are receiving this mail because: -------<br>You are on the CC list for the bug, or are watching someone who is.<br>You reported the bug, or are watching the reporter.<br></blockquote> </div><br> </span></div></blockquote></div><br>
Not a serious enough but to hold up the release of 6.3.
How huge are your audio files, Andi? Do you have any smaller than others that you could attach for us to have a look at?
Andi, If uploading isn't an option, please consider using www.dropload.com and sending the files to ross AT slimdevices DOT com
Not pervasive enough to hold up the 6.5 release.
Dropping the severity since so few people seem to be affected. Andi, we'd still love to have a closer look at one of your affected files if you get an opportunity.
Andi, I guess the files/CDs in question generally have little or no inter-track gap. Is that correct? You say they are ripped to 320kb/s VBR. Is that VBR with a max bitrate of 320, or is it really 320 CBR? I suspect the former. When SqueezeCentre parses a CUE sheet, it notes the start and end times of each track and converts these to start-offset and size (length), both measured in bytes. I do not think that it actually aligns these to frame boundaries, although it does use a frame-alignment method which may work for CBR files some of the time, and certainly does not parse the whole file to compute the correct frame boundaries for each given time-offset. When it steams such a track to a player, for playing, it just streams the so-defined chunk of data from the file. This can have two consequences: 1. Tracks may not start and end exactly on frame boundaries. Given that frames are 26ms long, this could (just) lead to the glitch you hear. It is possible that this will only happen with VBR files. 2. Tracks may not start and end exactly where they should. I have examined a few short (3-5 minute) VBR tracks and found that the time-offset of a particular byte-offset may be out by as much as +/- 8s from that obtained by a simple proportional calculation of the byte position. Of course, this should not be an issue when playing the tracks in sequence. Note that, when playing sequential tracks from a single file, SqueezeCentre sends these as individual streams. I think that this should not be an issue, however, other than the influence of the problems noted above.
(In reply to comment #0) > When playing large MP3 files that have their track information encoded within a > CUE file the music will momentarily skip as the player switches to displaying > the track information for the new track. The skipping sounds to be the result > of the player resynchronising the sound and playing the new track a fraction of > a second ahead of when it should start. The fault seems to appear when using > both version 6.2.2 and the 6.3.0 nightly build. Andi, If you close your browser, does the playlist execute without the glitch? I have the same problem running SC7.0 on a SB1. Is your SB an SB1? -Jim
Chris, I do not think that this can be fixed without some significant changes to the way we handle CUE files. Ideally the scanning process would locate the precise frame offsets for each track. Also, in the case of sequential track play, it would be better to stream he original stream uninterrupted across track boundaries, rather than the current mechanism of a stream per track; but this would be a significant change. In either case I think that it very unlikely that such a change would be suitable for 7.0. Alan.
Thank you for having a look at this, Alan. We can have another look at this for 7.1.
Perhaps it makes sense to work on this in concert with Alan's 'new streaming' feature of 7.2
New_streaming is in 7.3
It was not possible to incorporate this into new-streaming and I do not see much likelihood of it being incorporated in the near future. However, there were some improvements to frame-boundary seeking in 7.3.? which may improve things a little, but you are unlikely to get proper gapless playback in this case.
Andi: can you please try the latest nightly 7.3.3 to see if this address or changes the behavior you are experiencing?
This should be working much better now as VBR is handled properly now, so I'm marking this fixed. However, the transitions will not be truly gapless. For that, see bug 8877.