From: Hardeep Sidhu <hardeeps_at_pobox.com>
Date: Mon, 11 Jul 2005 19:35:10 -0700

Ryan Jackson wrote:
> On 7/11/05, Hardeep Sidhu <hardeeps_at_pobox.com> wrote:
>
>>Yes, I've noticed this too. I think the proper way to fix this to
>>update the offset based on how much has played, not how much has been
>>decoded.
>
>
> Right. Any idea how to do this? I was thinking along these lines (in
> pseudocode):
>
> if ( rb->stop_codec || rb->reload_codec ) {
> long elapsed = rb->id3->elapsed;
> seek_to_time_offset(elapsed); //pseudocode
> rb->id3->offset = get_raw_offset(file); //pseudocode
> break;
> }
>
> Something like this *seems* like it would work, but I'm not sure if
> this would be the right way to go about it. The only other 'solution'
> I can see is to store the elapsed time instead of the byte offset and
> then seeking to that time on resume. I'm not sure about that one
> either. :-/

The problem with using total elapsed time to determine offset is that it
can be quite inaccurate when dealing with VBR files (see
mp3_get_file_pos() for instance).

If we could associate file offsets with the pcm audio buffer (maybe for
every chunk?), that would give us the most accurate resume info. I'm
not sure how feasible this is though.

The simplest, although not as accurate, solution I can think of would be
to use the audiobuffer latency to calculate the difference between the
current offset and the last offset returned by the codec (similar to how
the elapsed time is calculated):
current_offset = last_offset - (audiobuffer_get_latency() * bit_rate);

-Hardeep
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-07-12