Sample accurate decoding from a generated FLAC seekpoint possible?

[gabrielwolf]

Thank you for your excellent work in making FLAC more accessible in WASM.

My question: If the decoder only has bytes to work with starting from the given byte offset of the respective seekpoint in the SEEKTABLE, is it guaranteed that the decoded PCM output will be starting sample accurately?

Frame size is fixed to 1024 during encoding with flac. Seekpoints are added via metaflac --dont-use-padding --add-seekpoint=2530x

Thank you for any insights...
I am trying to wrap my head around this for about 2 months now. :-)

Ps: Asked the question also on SO
https://stackoverflow.com/questions/79730367/is-sample-accurate-decoding-from-an-arbitrary-flac-seekpoint-possible

Best,
Gabriel

[eshaz]

Hi Gabriel,

If the decoder only has bytes to work with starting from the given byte offset of the respective seekpoint in the SEEKTABLE, is it guaranteed that the decoded PCM output will be starting sample accurately?

Yes it should decode that frame and additonal frames just fine. I believe the seektable is designed to be sample accurate, and you can just start decoding with the frame at the byte offset that's referenced in the table.

If you want to download and decode at the same time, such as downloading from an HTTP response ReadableStream, you should send the data into the .decode() method into chunks as you download. Just remember when you are done reading data to call .flush() so any buffered data is decoded. https://github.com/eshaz/wasm-audio-decoders/tree/main/src/flac#methods-1

Also, there are some helpful hints here to avoid blocking calls to .decode().

[gabrielwolf]

Thank you, @eshaz, for your suggestions. In the meantime, I managed to identify the bug in my code while using your method of avoiding await until the promise chain is fully built.

The problem was that I was fetching data directly from the frameOffset of a seekpoint without realising that this is a relative offset from the start of the first frame, rather than an absolute file offset in bytes.

The solution was to keep track of the flac file header size when parsing the metadata and then add that to the relative offset as a new key/value property. I posted the solution to my SO question.

Ps: Is it common to close an issue, if it is solved for the questioner? I didn't dare to press the 'Close with comment' button as this is not my repo... :)