Bugzilla – Bug 3712
"inesthetic" jump between songs while using soft squeeze and some music files
Last modified: 2008-09-15 14:39:24 UTC
See TMID 5801 for details, I'll attach the files to this bug as well.
Created attachment 1319 [details] music file 1
Created attachment 1320 [details] music file 2
Hi Ross, In the future, it would be great if you could include a brief summary in the bug description, so that I don't have to read the whole TMID. Also, the bug description is not great. The attached files appear to be MP3 files. Did you try to reproduce the bug?
(In reply to comment #3) > Hi Ross, > > In the future, it would be great if you could include a brief summary in the > bug description, so that I don't have to read the whole TMID. Also, the bug > description is not great. > > The attached files appear to be MP3 files. > > Did you try to reproduce the bug? > Being somehow at the origin of this bugreport, maybe I could give a brief description: In the process of switching from the first to the second MP3 file using softsuqeeze a split-second "hesitation" or "inesthetic" or "hesitation" sound occurs. This phenomenon is totally absent when using Sueezebox3. What else? I am using Firefox under Windows XP Home. The CD has been "ripped" using iTunes. The "sound" does not occur when moving betseen other songs of the CD. The CD is a "standard" off the shelf commercial product which plays normally when read directly. The two files reproduce 1. the first the two songs played using Squeezebox and 2. the same files using Softsqueeze. Other music ripped the same way plays normally using softsqueeze. I have not tested ALL my files. Regards
I listened carefully to both files, but couldn't tell any difference. I ran windows 'FC.EXE' (file comparison utility) and it tells me the files are identical. Honestly, I'd rather have files that I can play and reproduce the problem. Will look more at this in a bit.
Re-opening support ticket. Not enough information to reproduce this bug just yet, I will update this bug with what I find.
(In reply to comment #6) > Re-opening support ticket. Not enough information to reproduce this bug just > yet, I will update this bug with what I find. > I have listened to the two files I thought I sent Ross on the 6th/7th July using a hotmail address because of excess size problems. I have sent them again tonight. Sorry for any inconvenience caused
Created attachment 1340 [details] part one of a track that should be gapless and seamless original filename: gaptest-1-They Reminisce Over You (T.R.O.Y.)-mp3.mp3
Created attachment 1341 [details] part two of a track that should be gapless and seamless Original filename: gaptest-2-They Reminisce Over You (T.R.O.Y.)-mp3.mp3
Ross, try these two tracks on Softsqueeze. I thought I heard a crackle at the transition.
I did hear an odd hiccup. I've received THE files from Roger. I'll attach them. Please try listening to them.
Created attachment 1344 [details] truncated song file 1
Created attachment 1345 [details] truncated song file 2
In the MP3 file format there is not necessarily a correlation between the amount of audio data ripped and the amount of data in an mp3 file data frame. That is, the mp3 format, due to the nature of its encoding, may have empty samples in the last frame of the file. Dean tells me that in the LAME encoder there is apparently information placed in the header about how many 'empty' samples there are in the last frame that should be skipped. However, the current SB firmware does not obey that header information. This results in a problem for some mp3 transitions. Depending on the encoding, there may or may not be a gap at the end of an mp3 file. If reliable gapless playback is important, you should use any of the other supported audio formats. But not MP3. *** This bug has been marked as a duplicate of 1026 ***
(In reply to comment #14) > In the MP3 file format there is not necessarily a correlation between the > amount of audio data ripped and the amount of data in an mp3 file data frame. > That is, the mp3 format, due to the nature of its encoding, may have empty > samples in the last frame of the file. Dean tells me that in the LAME encoder > there is apparently information placed in the header about how many 'empty' > samples there are in the last frame that should be skipped. However, the > current SB firmware does not obey that header information. > > This results in a problem for some mp3 transitions. Depending on the encoding, > there may or may not be a gap at the end of an mp3 file. > > If reliable gapless playback is important, you should use any of the other > supported audio formats. But not MP3. > > *** This bug has been marked as a duplicate of 1026 *** > I wonder in which way this answers the question: why does the "hiccup" happen when playing with Softsqueeze and not with Squeezebox3?
Ah, because Softsqueeze implements a slightly different MP3 decoder than the Squeezebox.