Hello, nice crate! I had some trouble with reading a flac in claxon via creek (maybe too old?), and I decided to use yours because it doesn't force allocation for the reader (I want to pass [i16; N] for example), great work on the api!
My only question/hiccup was why does the input to e.g., read (https://docs.rs/flac-codec/1.1.0/flac_codec/decode/struct.FlacSampleReader.html#method.read) take i32s? The documentation suggests samples are always i16s, my tests indicate every sample is <= i16::MAX, and also, to my knowledge, i32 isn't really a PCM sample kind anyway. It would be nice if it were i16s, since this would use less memory for me on the stack fwiw 🤷
Lastly, I do notice occasionally the buffer i use, a [i32; 2048] is not fully populated, e.g., it reads 1024 samples every now and then. I currently have logic to consider the file read done when 0 samples are read, but I was wondering why that was happening.
Anyway, great crate!
Hello, nice crate! I had some trouble with reading a flac in claxon via creek (maybe too old?), and I decided to use yours because it doesn't force allocation for the reader (I want to pass
[i16; N]for example), great work on the api!My only question/hiccup was why does the input to e.g.,
read(https://docs.rs/flac-codec/1.1.0/flac_codec/decode/struct.FlacSampleReader.html#method.read) takei32s? The documentation suggests samples are always i16s, my tests indicate every sample is <=i16::MAX, and also, to my knowledge,i32isn't really a PCM sample kind anyway. It would be nice if it were i16s, since this would use less memory for me on the stack fwiw 🤷Lastly, I do notice occasionally the buffer i use, a
[i32; 2048]is not fully populated, e.g., it reads1024samples every now and then. I currently have logic to consider the file read done when0samples are read, but I was wondering why that was happening.Anyway, great crate!