Accurate seeking for LAME-encoded MP3s

Discuss the development and future direction of Play.
Post Reply
tipsch
Posts: 5
Joined: Tue Sep 25, 2007 1:05 pm

Accurate seeking for LAME-encoded MP3s

Post by tipsch » Fri Oct 26, 2007 3:12 pm

Changes in r1036:* Accurate seeking for LAME-encoded MP3s

I just noticed that while skipping fast through my mp3 library with Play now results in a lot irritating 2 second stops. Personally i really dislike this in my favorite lightweight/fast all-audio-format player. I'm just wondering if this could become an optional setting in future versions?

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Re: Accurate seeking for LAME-encoded MP3s

Post by sbooth » Fri Oct 26, 2007 3:38 pm

Accurate seeking is absolutely required for implementing cue sheets and gapless playback.

The problem is the MP3 format itself; it is just antiquated. To begin with the 'gapless' support is more of an add-on than anything, so it's not even guaranteed that you can determine how many audio frames exist in a file (since the encoder has a MDCT filterbank delay, the decoder has a delay, and the encoder pads the last MPEG frame). Plus, there is no way to seek to a certain frame of audio without decoding every preceding frame using brute force- hence the speed penalty. Xing headers make seeking more accurate, but not frame accurate. For cue sheets and for gapless playback, it is obviously necessary to seek to an exact point in the file.

In 0.2, seeking during playback of a gapless file will break gapless playback for that track. This is not a behavior that users expect! So the new behavior is to seek accurately in any file that contains a LAME header. I could consider changing this, but I'm disinclined to do so. foobar2000 has a similar issue (although undoubtedly they use a faster MP3 decoder): http://foobar2000.org/FAQ.html

tipsch
Posts: 5
Joined: Tue Sep 25, 2007 1:05 pm

Re: Accurate seeking for LAME-encoded MP3s

Post by tipsch » Fri Oct 26, 2007 4:22 pm

sbooth wrote:Accurate seeking is absolutely required for implementing cue sheets and gapless playback.

The problem is the MP3 format itself; it is just antiquated. To begin with the 'gapless' support is more of an add-on than anything, so it's not even guaranteed that you can determine how many audio frames exist in a file (since the encoder has a MDCT filterbank delay, the decoder has a delay, and the encoder pads the last MPEG frame). Plus, there is no way to seek to a certain frame of audio without decoding every preceding frame using brute force- hence the speed penalty. Xing headers make seeking more accurate, but not frame accurate. For cue sheets and for gapless playback, it is obviously necessary to seek to an exact point in the file.

In 0.2, seeking during playback of a gapless file will break gapless playback for that track. This is not a behavior that users expect! So the new behavior is to seek accurately in any file that contains a LAME header. I could consider changing this, but I'm disinclined to do so. foobar2000 has a similar issue (although undoubtedly they use a faster MP3 decoder): http://foobar2000.org/FAQ.html
Perhaps it needs finetuning, i really don't know as i'm not a programmer. I just noticed the huge difference (in a negative way) of Play's behavior and got concerned.

I did do a test on some of my own encoded gappless mp3 albums and gapless playback does indeed only work in the r1036. Comparing it to iTunes is another major difference as it offers accurate seeking and gapless playback. This actually makes me believe that you should implement it indeed, because iTunes shows fine behaviour+gapless playback IS possible. Play is still the finest tho. :-)
Last edited by tipsch on Fri Oct 26, 2007 4:31 pm, edited 4 times in total.

tipsch
Posts: 5
Joined: Tue Sep 25, 2007 1:05 pm

Re: Accurate seeking for LAME-encoded MP3s

Post by tipsch » Fri Oct 26, 2007 4:25 pm

Deleting this.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest