ruuda / hound

A wav encoding and decoding library in Rust
https://codeberg.org/ruuda/hound
Apache License 2.0
489 stars 65 forks source link

Add per-frame iterator #46

Open sdroege opened 4 years ago

sdroege commented 4 years ago

Currently there is only the samples iterator for reading files. It would be useful to have a similar iterator that gives a whole frame per iteration (i.e. one sample per channel in a slice) as that's usually the unit of processing.

A similar feature for the writer would also seem useful.

ruuda commented 4 years ago

Thank you for taking the time to open an issue!

It would be useful to have a similar iterator that gives a whole frame per iteration (i.e. one sample per channel in a slice) as that's usually the unit of processing.

Would iter::chunks suffice for this? You might think that Hound could do a more efficient job, but it is difficult in general, because the underlying interface is a Reader, not a slice.

A similar feature for the writer would also seem useful.

That sounds like it could be useful indeed, not just for frames but for arbitrary slices, to save the overhead of checking the result after every sample. Even more general would be to accept an iterator rather than a slice. I added SampleWriter16 with a similar intent, but it is "push based" in the sense that it still requires writing every individual sample. That is more general than an iterator though, because you can easily do .for_each(writer.write_sample) on an iterator, but turning something that is not an interator into one is a lot harder. Taking a slice could still be useful just as a convenience method though.

sdroege commented 4 years ago

It would be useful to have a similar iterator that gives a whole frame per iteration (i.e. one sample per channel in a slice) as that's usually the unit of processing.

Would iter::chunks suffice for this? You might think that Hound could do a more efficient job, but it is difficult in general, because the underlying interface is a Reader, not a slice.

That's what I'm doing right now, copying each sample of the frame into a pre-allocated slice on each iteration. That's a bit annoying and seems inefficient, but it works.

I can see the problem with Reader though and don't really have a suggestion how that could be done better :)