Skip to content
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

Question #2

Open
ronaldkunenborg opened this issue Feb 22, 2021 · 5 comments
Open

Question #2

ronaldkunenborg opened this issue Feb 22, 2021 · 5 comments
Assignees
Labels
question Further information is requested

Comments

@ronaldkunenborg
Copy link
Contributor

Hi Zuzu-Typ,

Can I ask what your plans are with this mod? There is also a WavFile reader and writer in SciPy (https://docs.scipy.org/doc/scipy/reference/generated/scipy.io.wavfile.read.html) that does part of this. They have a rather large community but change requests can take years. They're also focused on just reading/writing and less on metadata support.

I'd like to add some stuff, notably ChannelMask and speaker layouts, 24-bit support, and normalization support (the latter taken from SciPy.wavfile). My main interest is that I can: read all current formats I have on my harddisk (96Khz/24 bit, 32 bit floating point, 8-32 bit fixed), read and copy all metadata if required for a 100% accurate copy, and display normalized data on a (real time) plot.

If you don't want that, it's cool. But if you agree, I'll add a few pull requests here and there over the coming weeks.

Cheers,
Ronald.

@Zuzu-Typ
Copy link
Owner

Hi there Ronald,

I originally created this library to have a simple library that can read and write Wave files.
The only ones existing seemed to be the very limited wave module and very bloated libraries such as SciPy or PyAudio.

The wave format is very simple so a "header only" library is really all you need if you don't need support for any other formats.

Currently pretty much all my repos are "on hold" (i.e. I'm not working on them), because I have a lot of work and personal stuff to deal with that takes priority.
So I'm probably not going to work on this library for a while.

But if you would like to contribute, feel very free to do so (:
Beware though that this library was made with a "quick and dirty" approach, so I'm sure there are some leftovers and other stuff in there that aren't ideal.

Thanks in advance ^^

Cheers,
--Zuzu_Typ--

@Zuzu-Typ Zuzu-Typ self-assigned this Feb 22, 2021
@Zuzu-Typ Zuzu-Typ added the question Further information is requested label Feb 22, 2021
@ronaldkunenborg
Copy link
Contributor Author

Hi,

Thanks for your quick reply - I've seen projects where it would take months to get one :)
As for your assessment: I agree. Other libraries seem a bit overlarge, which is why I ended up with yours. Quick and dirty coding isn't a problem - I just started Python 3 weeks ago, so I doubt it's going to be better than your code, but I'll endeavor to maintain some standards :)

I'll let you know when I have something. The speakerlayout may or may not be a part of it, I'll make that it's own file or at least, class.

In the mean time, good luck with your work and other stuff, it's very relatable!

Cheers,
Ronald.

@ronaldkunenborg
Copy link
Contributor Author

Okay, another question: do you prefer pull requests, or issues with a description of the issue, and a description of the fix with sample code?

I have a number of items I'd like to have your opinion on as well:

  1. Hardening against incorrect WAV files. don't see any real bugs. But the software needs more hardening because about 4-5 out of 15 wavs failed to parse the metadata due to incorrect size metadata, misaligned chunks, and incorrect \x00 byte paddings in the WAV files. This is unfortunately a fact of life for WAV files.

  2. Metadata enhancement. The "fmt " chunk contains more metadata than currently reported, including some that can be calculated. This could be done by the party reading the file in some cases, but not always (FACT chunk info >> fmt info for compressed wavs). There is also codec information present, and I would like the PyWave to report that in text as well when requested, instead of just the WAVE-file code.

  3. Parsing more metadata chunks. There is already a parser one for the LIST.info subchunk (needs some hardening but otherwise fine). However, LIST has more subtypes and some might be interesting. I would also like to read a few more chunks that I encountered. Currently I have added code to parse BEXT and CART but I'm not yet happy with how messy this makes things and I have seen a better method. May need to be split off into a different file with a ChunkParse class? Then PyWave can just hand over the metadata as a collection of top-level chunks and the PyWaveChunkParser can give out information on the supported chunks. Reading all metadata for parsing by the end-user when desirable is then sort of required. I know this doesn't look very clear - I could give a code sample showing what I mean.

The chunks I would like to read:
"fmt " (duh)
"data" (duh)
LIST
INFO
adtl (never seen it but apparently some loop software can write this)
wvpl (never seen it, it's a stupid idea)
fact ( is actually a requirement for any wav-file other than PCM, apparently, according to https://www.appletonaudio.com/blog/tag/wave-file-format/)

I'm currently downloading some Looperman samples, and seeing a lot of weird stuff going on in those WAV files (https://www.looperman.com/loops/detail/241433/groovy-synth-bass-loop-michael-jackson-style-free-120bpm-dance-bass-synth-loop manages to have: bext, JUNK, Fake, fmt and data chunks - in that order!!).

  1. Adding a few more sample WAVs - have to be careful with copyright of course so we better make them ourselves - with some of the wilder chunk types I can see in real life, except with different sound data, might be good. Not sure if I really want to do this though. Have to see about whether it's worth the time and effort.

  2. Extending the example.py to display all the available metadata once it has been extended.

Anyway, just let me know how you'd like to see change requests: as issue or as PR. I'm fine with either but it seems less work for you to look at pull requests.

@Zuzu-Typ
Copy link
Owner

Zuzu-Typ commented Mar 1, 2021

Hey there (:

I would prefer pull requests, but feel free to create issue threads if you come across something you don't manage to implement yourself.

  1. Hardening against incorrect WAV files. don't see any real bugs. But the software needs more hardening because about 4-5 out of 15 wavs failed to parse the metadata due to incorrect size metadata, misaligned chunks, and incorrect \x00 byte paddings in the WAV files. This is unfortunately a fact of life for WAV files.

I know. The thing is kinda held together with toothpicks and glue. Since I only used it for working Wave files, I didn't put much thought to error checking. I agree, that should definitely be done.

  1. Metadata enhancement. The "fmt " chunk contains more metadata than currently reported, including some that can be calculated. This could be done by the party reading the file in some cases, but not always (FACT chunk info >> fmt info for compressed wavs). There is also codec information present, and I would like the PyWave to report that in text as well when requested, instead of just the WAVE-file code.

I think at the time I was working on this library I found it quite difficult to find reliable sources of information for the WAVE-Format. It seemed like all the websites I visited portrayed conflicting messages. Especially about the different WAVE format types and padding bytes. That's also why I didn't dare touching anything beyond the most basic metadata chunks. But sure, the more the better, right?

  1. Parsing more metadata chunks. There is already a parser one for the LIST.info subchunk (needs some hardening but otherwise fine). However, LIST has more subtypes and some might be interesting. I would also like to read a few more chunks that I encountered. Currently I have added code to parse BEXT and CART but I'm not yet happy with how messy this makes things and I have seen a better method. May need to be split off into a different file with a ChunkParse class? Then PyWave can just hand over the metadata as a collection of top-level chunks and the PyWaveChunkParser can give out information on the supported chunks. Reading all metadata for parsing by the end-user when desirable is then sort of required. I know this doesn't look very clear - I could give a code sample showing what I mean.

Seems like a good idea to me. Giving things a more object oriented structure would be a good idea in general. Right now it's kind of all over the place with lots of "magic values". Back then I didn't know better 😅

  1. Adding a few more sample WAVs - have to be careful with copyright of course so we better make them ourselves - with some of the wilder chunk types I can see in real life, except with different sound data, might be good. Not sure if I really want to do this though. Have to see about whether it's worth the time and effort.

Sure, especially for testing purposes this will be interesting. I just used what I had on hand to test it and downloaded a few more samples from the internet. Though of course I didn't publish those here.

  1. Extending the example.py to display all the available metadata once it has been extended.

Yupp, sounds like a plan (:

Thank you for your burning desire to contribute ^^
If you need help (and find the time for it), I will try my best to assist you (:

Cheers
--Zuzu_Typ--

@ronaldkunenborg
Copy link
Contributor Author

Cool, I'll start on preparing for it then :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants