Seeking

[mainrs]

Looks like seeking isn't supported for now. Do the used libraries allow seeking in general?
It's a feature I would need for an application and I would be willing to try to implement it. Not sure where though. The sink looks like a good place for it.

[est31]

Do the used libraries allow seeking in general?

Lewton does. Dunno about the other libraries.

[tomaka]

I guess it should first and foremost be implemented on the decoder struct, if the underlying libraries support it (which I'm not sure of).

[michaelmarconi]

Anyone get anywhere with this?
I need to skip 30 secs at a time through an MP3. Would it be possible to do this by Seeking in the underlying decoder?

[mainrs]

I couldn't really get it working and gave up on it 😢

[Lisible]

It's a feature I need too, unfortunately I don't have much time to try to implement it.

[slmjkdbtl]

@recapitalverb I only had success with seeking with hound (hound::WavReader::seek) + cpal, fitting this into rodio might be some work, you can probably add a seek method to Source and only implement if for WavDecoder

[slmjkdbtl]

@michaelmarconi Yes you can seek any format that way but it'll take a lot of time to parse the whole audio file, it's the best way if you're fine with that

[est31]

Yeah it'd be very CPU and RAM intensive and not a good idea. Some people may want to play back 10 hours of background music or something all in one file...

[mainrs]

Yeah it'd be very CPU and RAM intensive and not a good idea. Some people may want to play back 10 hours of background music or something all in one file...

Aren't (almost) all audio formats streamable? At least that's what I always thought... You could then load an interval of like 1min into RAM and keep it there at any given time and just continuously load new content and drop the old one.

[est31]

Already 1 minute of samples at 48000 samples per seconds with 2 bytes per sample would mean 5760k or 6 mb of memory use. If it's an opt-in feature, people can use it if they want but optimally one would have seeking support in all of the libraries that rodio uses, then make rodio abstract over it.

[TonalidadeHidrica]

Eager for the seeking feature for this library, I looked up for each underlying decoder library:

MP3

minimp3-rs, has no feature for seeking, though the original C library minimp3 does.

High-level mp3dec_ex_seek function supports precise seek to sample (MP3D_SEEK_TO_SAMPLE) using index and binary search

There is a fork that adds a wrapper to the seek function in the original library, last updated on May 2020, a half year ago. The implementation wraps mp3dec_ex_seek, which enables sample-level seeking.

WAV

hound does provide sample-level seeking.

Vorbis

lewton provides a seeking function OggStreamReader::seek_absgp_pg, which provides with per-page seeking.

Related: RustAudio/lewton#73, and maybe RustAudio/lewton#16 as well? Any updates? @est31

FLAC

claxon is used. According to this issue comment, "Claxon currently does not support seeking".

Some FLAC files have "SEEKTABLE" metadata, so this may help for implementing the feature. Even if there is no such metadata, one can still seek to arbitrary position and look for the frame header, which contains the frame position, so it is easy to implement binary searching.

[dvdsk]

I needed seeking for my podcast player build on rodio. I now have it working (in the most basic way possible) for mp3 on my fork. For that I added:

• a new member function for sources that can seek called request_pos which takes a float that is the duration from the start of a source to seek to (in seconds).
• an Option<f32> field set_pos to the controls struct that is used by the sink to modify playback.
• a member function set_pos() to the Sink that is used to set the field to some position.
• a check if the field is not None within the periodic_access closure. It takes care of calling the member function request_pos() of the source and setting the field back to None.

However sources might not support seeking thus we can not simply add request_pos() to the Source trait. For now I only added seeking to the mp3 decoder. Sources that build upon a source, think of the Mix struct, complicate this further. What to do if only one of the two sources mixed supports seeking? For now I added the request_pos() function under a new trait SourceExt. I implemented if for the structs:

• Decoder<I>
• Pausable<I>
• Stopable<I>
• Amplify<I>

where <I> has the trait SourceExt. I do not know if something like this would work for the other sources/structs. I suspect not. Has anyone got an idea how I could improve this? Should I open a PR and work on it there?

PS: I forked the fork of minimp3-rs mentioned above, brought it up to date with master and extended it to allow decoding a whole frame. It is used as a git dependency here instead of minimp3-rs on crates.io