PDA

View Full Version : Gapless playback not working?



dekaliber
2007-01-25, 07:56
I was pretty ecstatic about the release of gapless playback for MP3 in v.6.5.1. However, it doesn't seem to be working for me... I did a search for troubles with this issues but was unable to find anything conclusive.

I've used the pcutmp3 tool (http://www.hydrogenaudio.org/forums/index.php?showtopic=35654&st=0&p=314305&#entry314305 ) to split a number of mp3/cue files that I have. These are generally DJ sets that started out as one mp3 with a cue file, and since I prefer having individual files I can select, I use pcutmp3 to split the mp3 along the cue positions without reencoding the file. While it plays back beautifully in something like foobar2000, there is a very pronounced 1/2 second or so gap between the songs when I play them back with my Squeezebox v3 (the wireless version, if it makes any difference).

It doesn't seem justified to re-encode them as FLAC to take advantage of gapless support that way, and I'd rather not transcode them to OGG...

So, what I'm wondering is, is gapless MP3 playback a feature I have to manually activate somewhere in my server settings? I took a look but didn't see anything obvious. Alternatively, am I doing something wrong?

Any help or advice would be greatly appreciated!

Ben Sandee
2007-01-25, 08:10
On 1/25/07, dekaliber <
dekaliber.2kz1dz1169737201 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> So, what I'm wondering is, is gapless MP3 playback a feature I have to
> manually activate somewhere in my server settings? I took a look but
> didn't see anything obvious. Alternatively, am I doing something
> wrong?


Gapless MP3 in SlimServer requires that the MP3's be encoded using more
recent versions of LAME that include the necessary audio offset. Unless
your tool is supposed to replicate those headers somehow, I would be
surprised if it was supposed to work.

Ben

andyg
2007-01-25, 08:15
Couple of ways to check if gapless is working.

First, do a complete wipe and rescan of your library just to make sure SlimServer picks up the gapless info properly.

Then, run SlimServer with --d_source debugging enabled. It will display something like this for all mp3 files played:

MP3 file was encoded with LAME3.93
MP3 file contains encoder delay information (xxx/yyy), will be played gapless

Or if it's not gapless or LAME, you'll get one of these 2 messages:

MP3 file was not encoded with LAME, will not play back gapless

MP3 file does not contain encoder delay information, will not play back gapless

dekaliber
2007-01-25, 08:25
Thanks gents for the quick reply!

Here's how pcutmp3 is supposed to work. It sounds like it's embedding the appropriate LAME data, but I might be misunderstanding something:


How it works:
This app analyzes the source mp3 file and its Xing/Info/LAME tag and allows cutting it at *any* positions through the use of the LAME tag's encoder_delay/padding fields. It generates for each track you crop out of the large source file a new Xing/Info/LAME tag frame filled appropriately and resolves the problem of missing bitreservoir data via a "silence frame" (holding the missing data) that directly follows the Xing/Info/LAME tag frame. This additional delay (due to this "silence frame") is also compensated via the encoder_delay setting which explains the high values it produces (576...2879). It should be possible to rejoin files losslessly (not yet implemented).

Andy, pretty sure I've rescanned everything since installing 6.5.1. I'll try running SlimServer with debugging on when I get home.

andyg
2007-01-25, 08:26
OK, sounds like it should work from that description. If you want to upload 2 small consecutive files somewhere, I can check them out.

dekaliber
2007-01-25, 08:34
Thanks again, Andy! I'll upload a couple of files when I get home for you to take a look.

dekaliber
2007-01-25, 23:29
Hi again... Turned on debug mode and I see the following relevant data:

2007-01-26 00:16:59.7367 openSong: seeking in 2204 into C:\~music\_albums\Shpongle - Nothing Lasts... But Nothing Is Lost\04 Shpongle - Periscopes of Consciousness.mp3
2007-01-26 00:16:59.7597 MP3 file was encoded with LAME3.90.
2007-01-26 00:16:59.7599 MP3 file contains encoder delay information (1920/2220), will be played gapless

and the next track...

2007-01-26 00:18:44.2560 openSong: seeking in 2193 into C:\~music\_albums\Shpongle - Nothing Lasts... But Nothing Is Lost\05 Shpongle - Schmaltz Herring.mp3
2007-01-26 00:18:44.2582 MP3 file was encoded with LAME3.90.
2007-01-26 00:18:44.2585 MP3 file contains encoder delay information (2388/2220), will be played gapless

There a lot of other stuff, but at least from this it looks like the files are encoded with LAME and should be played back gaplessly, right? The encoder delays are quite long. Could that be a problem?

I've uploaded the two sample files in question, which are among the shortest consecutive ones I could find with this problem. Thanks for taking a look!

http://www.dekaliber.net/_etc/04_periscopes_of_consciousness.mp3
http://www.dekaliber.net/_etc/05_schmaltz_herring.mp3

andyg
2007-01-26, 05:32
Heh, the same album I use for gapless testing. :) I'll give your files a try a bit later this morning. I have mp3's encoded from FLAC of this album and they play fine, but they have more normal delay values.

andyg
2007-01-26, 08:54
OK so I went and listened to your files, and to my own encoded versions as well. Both sound the same, but actually there is a small "click" between the tracks, not a 1/2 second gap by any means, but it doesn't sound the same as my FLAC and Ogg versions.

Is this what you hear? I also tested with each replay gain setting, but it didn't make any difference.

dekaliber
2007-01-26, 16:45
When I listen to them on my Squeezebox there's a pretty noticeable gap. I might have exaggerated in my estimation of 1/2 second. Listening again it seems like it might be closer to 1/4 second...but definitely enough to cause a missed beat or two.

Yesterday when running in debug mode I noticed some suspicious events that said something to the effect of "sending 0.25 seconds of silence." I wasn't sure if that's normal behavior. I wonder why it would do that? I can send those debug lines to you if you think it might yield some more clues.

Asking around on the pcutmp3 tool (the app I used to cut the MP3s) topic on Hydrogenaudio, it seems like the app creates abnormally long encoder delays (around 2000). That was causing gapless playback to fail in iTunes and older versions of Foobar2k. To your knowledge, would it be possible that it's causing problems for the Squeezebox too? Quoted from the site:


WARNING:
Your player needs to properly support the LAME tag. If it doesn't you'll hear gaps. I tested it with Foobar 0.8.3 and Foobar 0.9 beta 5. Unfortunately the older one ignores encoder delay values above 1152 in the LAME tag (edit: see post #5 for Foobar 0.8.3). Since pcutmp3 usually creates mp3 files with encoder delays of around 2000 samples it won't work in Foobar 0.8.3. In combination with Foobar 0.9 beta 5 it works like charm. WinAMP + otachan's in_mpg123 + some good output-plug probably also works fine. So, use this app only if it makes sense to use it. The number of players which properly interpret the LAME tag is pretty low !! If your player does you can use pcutmp3 to do sample granular cuts.

Thanks again for your help, Andy.

andyg
2007-01-26, 17:05
When I listen to them on my Squeezebox there's a pretty noticeable gap. I might have exaggerated in my estimation of 1/2 second. Listening again it seems like it might be closer to 1/4 second...but definitely enough to cause a missed beat or two.

Yesterday when running in debug mode I noticed some suspicious events that said something to the effect of "sending 0.25 seconds of silence." I wasn't sure if that's normal behavior. I wonder why it would do that? I can send those debug lines to you if you think it might yield some more clues.


Check Player Settings -> Audio -> Audio Startup Time, that would cause the "sending 0.25 seconds of silence".

dekaliber
2007-01-27, 00:19
Aha! That definitely made the gap much, much shorter. No wonder. Thanks!

It's still not 100% gapless (it is, as you mentioned, a bit of a stutter), but it's good enough that I won't make a fuss. Is this as good as it's going to get (short of reencoding in FLAC or OGG)?

quick_snack
2007-01-27, 07:46
Foobar2000 produces perfect gapless playback. What's so difficult to build it into Slimserver? A few months ago I read gapless playback was covered but now I understand that gaps still exist (but as a sort of stutter).

I thought that by removing trailing silence-frames at the end of the track and replacing them with the next song (after removing leading silence-frames) would result in perfectly gapless playback.

I have had a SB1 for a couple of years and yesterday I upgraded and received my new SB3. I expected to enjoy gapless playback but was very disappointed.

When switching on the debug d_source the logfile let me know that tracks will be played gapless. So nothing wrong with my tracks or lame-tags.

ChrisOwens
2007-01-29, 16:55
I've reopened the gapless MP3 bug http://bugs.slimdevices.com/show_bug.cgi?id=1026 for this issue.

dekaliber
2007-01-29, 17:04
Great! Hopefully you guys will come up with something. Maybe checking out Foobar2000's source code and their implementation of gapless playback might yield some insight?

Thanks for providing such great support. I'm happy to say that this is the only flaw I've experience with my Squeezebox so far.

ChrisOwens
2007-01-29, 17:20
If I recall correctly, gapless MP3 playback involves some extra information in the header of the file that says when audio should end.

MP3 files are composed of chunks of fixed sizes, so depending on the length of the audio, there will almost always be a gap at the end of audio playback which is the leftover empty space in the current chunk. So, to decode gaplessly the decoder needs to know when to stop playing even though there is technically the remainder of the chunk (which happens to be silent) left to play.

This is why bugs in this area are more apparent with some files than with others.

Since you've linked to some example files, hopefully this should be easy for Richard to reproduce. I won't guess how easy it will be to _fix_, though! :-)

quick_snack
2007-01-29, 18:55
When I as example read the tags from my first track of Roger Waters' Amused To Death I see:

<ENC_DELAY> : 576
<ENC_PADDING> : 1164
<EXTRAINFO> : VBR
<MP3_ACCURATE_LENGTH> : yes
<MP3_STEREO_MODE> : joint stereo
So I think the number of frames to be skipped is known. I don't know if it is difficult to program slimserver to generate a gapless mp3 stream out of it.

The frames are fix length? Thus, by removing the beginning number of frames told by ENC_DELAY and removing the number of trailing frames told by ENC_PADDING we would have a accurate length mp3. The next song (also trimmed on both sides) could be pasted at the end of the previous mp3 (i.e. for the number of padding frames to follow the mp3 protocol). I would think it can be worked out that way.

Nevertheless, many thanks for reopening this bug (or will it be a feature :-))

rtitmuss
2007-02-08, 07:32
I've been looking at but 4750 (http://bugs.slimdevices.com/show_bug.cgi?id=4750) today to see why the files split by pcutmp3 don't work.


Asking around on the pcutmp3 tool (the app I used to cut the MP3s) topic on Hydrogenaudio, it seems like the app creates abnormally long encoder delays (around 2000). That was causing gapless playback to fail in iTunes and older versions of Foobar2k. To your knowledge, would it be possible that it's causing problems for the Squeezebox too?

Well you were spot on, the firmware was not handling the longer encoder delays correctly. This is fixed in Squeezebox firmware 75, it's in test now but look out for it in a nightly soon.

Richard

quick_snack
2007-02-08, 07:42
I have noticed that [Bug 1026] Implement gapless playback for MP3 is been resolved.

I am using the debian repository (deb http://debian.slimdevices.com testing main) from slimdevices for installing and using slimserver. Current firmware = 72

When will I be able to test the solution?

rtitmuss
2007-02-08, 07:56
I have noticed that [Bug 1026] Implement gapless playback for MP3 is been resolved.

Gapless playback for MP3 has been working since the release of 6.5.1. A few tracks were not played back correctly, examples were posted by dekaliber earlier in this thread. These tracks will work with firmware 75, it's in test now but expect to see this in a nightly release soon.

If your tracks still don't work correctly once you have the new firmware then please open a new bug with a couple of example tracks and I'll have a look.

Richard

quick_snack
2007-02-11, 07:32
Today downloaded the newest test version of slimserver (6.5.2 - 11395 - Debian - NL - utf8) but sticked to firmware 72.

I wonder at what term I can test the new changes...

The files (among many others) that cause problems are attached.
There is a noticable hick-up/stutter in the applause of the crowd.

Hmmm, I am not able to upload mp3's ?

quick_snack
2007-02-18, 14:51
Februari, 18th. No update...

When can I expect to download the new testversion?

andyg
2007-02-18, 14:53
Are you using the latest 6.5.2 build with firmware 76?

quick_snack
2007-02-18, 14:57
No I am currently using firmware 72, see my earlier post.
When I do apt-get update no new slimserver versions will show up.

andyg
2007-02-18, 14:57
http://www.slimdevices.com/downloads/nightly/latest/6.5/

quick_snack
2007-02-18, 14:59
I am using the debian install (repo) from:


deb http://debian.slimdevices.com testing main

andyg
2007-02-18, 15:02
Yeah, don't know why that isn't working for you, but you can grab the deb and install manually if you want.

quick_snack
2007-02-18, 15:11
After a remove and a new install i have:

SlimServer versie: 6.5.2 - 11466 - Debian - NL - utf8, firmware 76

Thanks!

teppic
2007-03-03, 04:17
I'm not getting reliable gapless playback with MP3s. I've tried the latest 6.5.2 daily builds and the stable 6.5.1. Sometimes there's no gap at all, sometimes a tiny click, sometimes a small gap.

The MP3s are encoded with lame 3.97 (-V2 --vbr-new) from Flac files directly ripped from CD. The Flac files play gaplessly perfectly, as do transcoded Ogg Vorbis files. Also these same MP3s play gaplessly without any problems in iTunes 7.

Hercules
2007-05-02, 03:18
I had an interesting experience with pcutmp3 earlier this week.

I used it to cut up a mix album into separate mp3 files, and then added the files to my SlimServer music directory, and rescanned.

When I tried to play back the new files, my Squeezebox seemed to work ok, but there was no audio, and the playback froze, in that the progress bar wouldn't move forward.

And once that had happened, the Squeezebox wouldn't play back any other music, even though I could still use all the menus etc.

The only way to correct the problem was to reboot the Squeezebox. If I then tried to play back different music (to the newly-split mp3 files) then everything worked ok. But as soon as I tried to play the new files, it would freeze again.

It was definitely caused by the newly-split mp3 files, because when I removed them - or just didn't use them - it all started working ok again!

So, to get to my point, I came to the conclusion that pcutmp3 was doing something to the mp3 files that somehow made them incompatible with my Squeezebox/SlimServer.

andyg
2007-05-02, 05:04
Could you please file a bug and attach one of the killer mp3 files to it?

andyg
2007-05-02, 05:07
You may also want to try some alternate mp3 splitters:

mp3splt (http://mp3splt.sourceforge.net/) (Linux/Mac/Win, also splits Ogg)
mp3DirectCut (http://mpesch3.de1.cc/mp3dc.html) (Win)

Hercules
2007-05-02, 05:36
Sure, will do so later tonight.

For info, I did raise a support call (070430-002964) for my original problem about the Squeezebox not playing back music, but closed it after working out what the problem was. The person working on the call was very helpful!

Thanks for the recommendations for other splitters - I'll check them out.

Funnily enough, I chose the pcutmp3 splitter deliberately! I did so because I had read glowing reports on hydrogenaudio about its ability to split single mp3 files in a way that would guarantee gapless playback.

Hercules
2007-05-02, 12:09
I have just submitted the details of my problem as bug 4959.