You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using opusfile 0.10.0, when calling op_read_float with a small buffer the function suddenly reads data from a totally different part of the stream.
This results in awkward noises and overall wrong output data.
Have a listen to this file from mozilla: detodos.zip (downloaded from here)
And now listen to the same file processed by opusfile: out2.zip
What I did was very simple.
I try to read data in packets of 5760 samples like so:
Create a buffer that can hold 5760 float samples
Read at most 5760 samples using op_read_float (buf_size set to 5760)
Using the returned number of samples actually read, computing the remaining samples (i.e. remaining = 5760 - numOfSamplesRead)
If remaining is 0, return the buffer and end the loop
Read at most remaining samples using op_read_float
Compute remaining samples and go to step 4.
It appears that whenever remaining has a very small size (such as 312 samples), the data is read from a completely different part of the file.
This is supported by the fact that it happens in the same intervals and that it occurs less frequently with larger buffer sizes.
Haven't tried the same for op_read.
The text was updated successfully, but these errors were encountered:
We weren't able to see the issue following these steps. Could you please provide full code which reproduces the issue? You might also try your current setup against git master in case that makes a difference.
I hope that I'm not being disruptive by bumping such an old issue, but I think it's worth noting that you have to adjust the pointer to the buffer to account for the number of samples that have already been read before performing step 5, otherwise the samples at the start of the buffer would be overwritten. I wonder if the author of this forgot to do so, especially as their example output sounds like the result of that potential mistake.
Using opusfile 0.10.0, when calling op_read_float with a small buffer the function suddenly reads data from a totally different part of the stream.
This results in awkward noises and overall wrong output data.
Have a listen to this file from mozilla: detodos.zip (downloaded from here)
And now listen to the same file processed by opusfile: out2.zip
What I did was very simple.
I try to read data in packets of 5760 samples like so:
remaining = 5760 - numOfSamplesRead
)remaining
is0
, return the buffer and end the loopremaining
samples using op_read_floatIt appears that whenever remaining has a very small size (such as 312 samples), the data is read from a completely different part of the file.
This is supported by the fact that it happens in the same intervals and that it occurs less frequently with larger buffer sizes.
Haven't tried the same for op_read.
The text was updated successfully, but these errors were encountered: