search

mackron / dr_libs

Audio decoding libraries for C/C++, each in a single source file.
Other
1.24k stars 205 forks source link

support decoding wav without seeking #212

Closed ahicks92 closed 2 years ago

ahicks92 commented 2 years ago

I have no idea how hard this would be, but my understanding of the wav format is that you don't need to seek. I'm trying to support some use cases where onSeek isn't available and/or is nonfunctional, and with dr_flac and dr_mp3 that's fine, but seems like for dr_wav you need to support it. Is there a way to make this happen as things stand, and if not any chance that we could get one?

For what it's worth I don't care about non-audio chunks in this scenario.

mackron commented 2 years ago

This isn't something I'm interested in I'm sorry. It's just that this requirement is way too niche relative to the amount of maintenance work required. I don't want to be dealing with the added permutation of dealing with onSeek being unavailable.

One thing you can experiment with is to implement the onSeek callback such that drwav_seek_origin_start results in an error, and then implement the drwav_seek_origin_current case in terms of a read-and-discard. I'm not sure how that would work out, but certainly drwav_seek_to_pcm_frame() will fail, and I think you might get errors if you try initializing with metadata.

ahicks92 commented 2 years ago

that's fine. As someone who also gets way too many issues/questions for niche features I totally get it. But for my curiosity, is it hard because of the maintenance burden on the library, or hard because the format makes it difficult?

mackron commented 2 years ago

From a pure audio extraction point of view you can certainly do it without a seek, but there's more to it than that in dr_wav. Here I do metadata extraction and seeking which requires some kind of seek implementation. It's not so much that it's hard, it's just annoying.

Do you have a specific case where this would be particularly useful? If that workaround I mentioned above doesn't work (error on drwav_seek_origin_start, read-and-discard otherwise), I might be interested in supporting that, but only if it's a relatively simple change.

ahicks92 commented 2 years ago

I'm offering an interface that lets users hook decoding up to any stream they want and it basically just says "if you don't have seek it won't work with everything". SO far no one has complained. It's probably not worth the effort on your part if it's effortful and for my part I'm probably just going to leave this alone until someone presents me with a good use case. I skimmed the code and came to the conclusion that I had no idea if this was a 5 minute problem or a 5 day problem, but I don't have more than (say) an hour problem worth of reason to actually do it. As long as mp3 doesn't lose the functionality I suspect no one will ever notice on my side.