-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chunk padding not recognized #90
Comments
I've fixed the issue, and while I was at it I've also fixed the restriction of the format and data chunk order. I cannot be bothered to fork and make a pull request, so here's my new version of wavread in WAV.jl:
|
mgkuhn
pushed a commit
to mgkuhn/WAV.jl
that referenced
this issue
Oct 3, 2020
up the entire chunk size. I have encountered WAV files with chunk padding, that means the next chunk starts only after a few unused padding bytes. Before reading the next subchunk header, you should explicitly seek to the next subchunk start as indicated by the actual chunk size in the chunk header instead on relying on things lining up. I've fixed the issue (dancasimiro#90), and while I was at it I've also fixed the restriction of the format and data chunk order.
A slightly fixed version of that fix is now PR #91. |
Fixed by #91 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current parser assumes that the data fields in a (sub)chunk fills up the entire chunk size. I have encountered WAV files with chunk padding, that means the next chunk starts only after a few unused padding bytes. Before reading the next subchunk header, you should explicitly seek to the next subchunk start as indicated by the actual chunk size in the chunk header instead on relying on things lining up.
The text was updated successfully, but these errors were encountered: