3D audio file display

[jersmi]

Yeah, I have that WaveFormat page open, too. Looking forward to seeing how you unpack the header, I have been struggling with how to get readable parts out of it by converting data to text. For example:

I appreciate the tutorial approach, and the general effort and guidance. My project is still specific to wavetables. The .wav files I will use will always be mono, 16-bit, 44.1k, linear PCM – most standard .wav format. Once again, a wavetable is a series of 16 single cycle waveforms, each precisely 2048 samples long (no silence). Other wavetables have more or less waveforms and different cycle lengths, though likely always some 2^n (256-4096). This is a standard format for wavetables used in many wavetable soft synths. I want to slice the n waveforms into a 3D view.  

[MartinusMagneson (Magneson)]

@jersmi See if the attached files makes any sense to you, and I’d appreciate it if you have any feedback on it :)

You shouldn’t need the attached composition/module, but they can be handy as a reference

VuoDataTutorial.zip (2.24 MB)

[jersmi]

Received, @MartinusMagneson. This is a very generous thing you have done. You mean you want feedback on the doc? I was able to follow along, nice job making the general comp sci info understandable for the likes of me, appears to have cleared up my questions, I’ll see when I try to apply it to my scenario. Could use a little polish, I suppose – section headers, esp. for general info and Vuo related, maybe a bit more at the end about applying the concepts to other file types (if this is a general tutorial). Could these built-in Vuo techniques be applied to image or 3D object data, glitch art, things as such? And that Calculate List section, I’m still wondering if that calc could/should be simplified with constants. At any rate, my turn to try and apply the concepts.  

[jersmi]

Ok, an issue. Turns out a bunch of the files I am using are 32-bit .wav files. Right now the Read Wave Header subcomp only handles “standard” 16-bit PCM. It will need an additional part (and maybe an if/then test?) to handle the extra byte chunk for format type 3/32-bit (see the non-PCM data table here):

http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html  

[jersmi]

Here’s a mod of the Read Wave Header subcomp which adds the extra header chunks to read the longer header for 32-bit float files (non-PCM). Thanks again, @MartinusMagneson, that subcomp was super helpful. This one outputs a length in samples, which then allows a calculation for byte count of the audio data, hope I got it correct – sub-chunk 2 size * sample length.

Edit: I learned that the 32-bit float sound files I am using were generated with libsndfile, which automatically adds PEAK/16 byte chunks (discovered after adding the extra header chunks):

chunkID: PEAK
chunkDataSize: 16 

There is a “feature” to PEAK that generates a normalized peak value/position structure, but I don’t know how to check if it is embedded in the data or not. Bottom line: I’m still trying to understand why my 32-bit float waveforms are not outputting correctly to the viewer (still look the same as the pic posted above), so being fuzzy about PEAK/16 keeps it on the table as a possible culprit.  

mm.readWaveHeader2.vuo (13.6 KB)

[MartinusMagneson (Magneson)]

Thanks for the feedback! I don’t always write simple/clear enough so it’s golden to get something like that to iron out the wrinkles. Vuo has a build in data to image node, but I’ll see about examples for other uses. The tutorial should possibly be split into chapters as well to give more bite-sized approaches to it, the full thing can take some time to get through.

With 32-bit files, you need to take the byte count more into consideration as you have 4 bytes per sample. I didn’t write much about automating this from the header data as it would get even longer (chaptering it out might be a way to include it). You can divide the byte-rate by the sample rate to get the bytes per sample, and use that output to set the Comb List pick/skip count.

Having more chunks means you’ll also have to offset the start of the read to 45 + the bytes of the additional chunks. Ideally there would be a “Find in Data” node (or something like that) for scanning the file and provide the byte location of the “DATA” chunk-ID. Then you’d be able to use that to get to the starting point relatively easy. For now I think it will have to be a manual process though.

[jersmi]

With 32-bit files, you need to take the byte count more into consideration as you have 4 bytes per sample. I didn’t write much about automating this from the header data as it would get even longer (chaptering it out might be a way to include it). You can divide the byte-rate by the sample rate to get the bytes per sample, and use that output to set the Comb List pick/skip count.

Helpful, though I need to review what the four bytes/sample do and which are useful. Put this in the chapter, “Now, how can this header mumbo jumbo actually help you manage the data?” :-)

Having more chunks means you’ll also have to offset the start of the read to 45 + the bytes of the additional chunks.

That’s right — see the manual approach in the mod of your subcomp above, Read Wave Header 2.  

[MartinusMagneson (Magneson)]

That is a good chapter title! The bytes are still little-endian, you just need to use the 4-byte conversion instead of the 2-byte conversion.

[jmcc (Jean Marie)]

Ideally there would be a “Find in Data” node (or something like that) for scanning the file and provide the byte location of the “DATA” chunk-ID. Then you’d be able to use that to get to the starting point relatively easy.

Magneson,

Please create a FR if you’d like that functionality. @smokris noted: “WAV files are RIFF-format and thus can contain arbitrary binary data. Simply searching for the text DATA in the file won’t always work — the binary data might happen to match the text DATA, then the composition will mistakenly think that’s a chunk header rather than the arbitrary data that it is.”

Also of interest is the feature request for Decode Audio Frame.

[jersmi]

Yeah – if one knows the .wav file compression format, then one can “manually” sort out the header data, correct? That is, I understand that .wav is a container for multiple compression types.  

[jmcc (Jean Marie)]

This is what Wikipedia says:

“The WAV file is an instance of a Resource Interchange File Format (RIFF) defined by IBM and Microsoft. The RIFF format acts as a “wrapper” for various audio coding formats.”

[jersmi]

@jmcc, thanks for the Wikipedia, apologies if my response seemed behind the curve here. I was just processing that users can still manage the data in .wav files with available Vuo tools if the user can sort out header + data structure if the compression type is known, indicated in header byte chunks (using something like @MartinusMagneson’s subcomp or whatever).

And acknowledging that it would not be practical for Vuo devs to put out a “find in data” to cover all .wav compression types (cuz I have no idea what the range of possible byte orders there might be out there with proprietary types, etc.).

I am still stumped on getting my 32-bit float .wav to output correctly. I’m pretty sure I have the header+data sorted, I just haven’t figured out how to parse the waveform data. Should look like 16 continuous sine waves, but mine still looks like the pic.

 

[MartinusMagneson (Magneson)]

@jmcc Yup, I don’t think my thoughts around how such a node should/could work is complete or backed by enough knowledge about how to deal with it yet either. I’ve read a bit more on the RIFF format/spec, and it gets even worse. The WAVE spec does not specify a distinct order of the chunks, meaning that you can stumble across something that place the DATA chunk before the FORMAT/FMT chunk. Not good practice, but not disallowed either.

The official spec is here: https://www.aelius.com/njh/wavemetatools/doc/riffmci.pdf (starting on page 56 for WAVE)
I however found a more informational explanation here: https://sites.google.com/site/musicgapi/technical-documents/wav-file-format which is where it’s mentioned that chunks doesn’t need to be ordered in a specific way. It also lists a bunch of chunks to consider, which can be pretty cool for creating WAVE files from data with included cues, playlists and MIDI information.

@jersmi can you cut the length of your data down to one cycle to see what’s happening and post the pic of that? You have 32 sine-like peaks in there with something in between (might be because of the scaling). Dividing your data byte count by 32 should place you somewhere around one cycle depending on the stuff at the end.

[jersmi]

Yeah, thanks, @MartinusMagneson. Logically I would divide my data by 16 – the test wavetable is 16 sequential sine waves. I’ll see what I can do.

The good news is that LPCM is by far the most used, and covering a few can cover a lot of ground. I know there can also be proprietary stuff for specific hardware/software, video cameras, game consoles. Then in addition to all the stuff in the doc you sent, there’s also other types of metadata. For ex., here’s an info page from the US Library of Congress on efforts to standardize and specs for embedding metadata.

Collecting more links to possibly refer to:

https://www.sounddevices.com/32-bit-float-files-explained/  

[MartinusMagneson (Magneson)]

@jersmi Yup, and by having 16 sequential sine waves you should have 16 upwards pointing peaks, and 16 pointing downwards. From your image it seems like you have 32 peaks pointing upwards with something in between. As this is also repeating, it will be beneficial to “zoom” in on just one half-cycle of the main sine which would be 1/32 of the full image. By the looks of the wave it seems like the frequency of the part I’d expect to be at the negative range is quite a bit higher. Can you also try with a sine wave from the link I posted with the parameters I provided? Then you can check if the composition works as intended with the expected source material to see if it is the input that differs or if it is the composition that does something funky.

[jersmi]

Still haven’t had to time to dig in with this, but I can at least report that the sine wave file you posted works fine, as well as any other 16-bit single cycle file I have on hand. Apparently something about the 32-bit float type that needs to be sorted. Byte order? Conversion calculation?  

[jersmi]

Ok – success if I convert the 32-bit float .wav to 16-bit integer. Attached zip file includes comp, updated subcomps and .wav files.

Here’s what I did to get things working. First thing was to set up some fresh analysis using Terminal:

https://wiki.lazarus.freepascal.org/macOS_Sound_Utilities

Used afinfo on my 32-bit float file:

File type ID:   WAVE
Num Tracks:     1
----
Data format:     1 ch,  44100 Hz, 'lpcm' (0x00000009) 32-bit little-endian float
                no channel layout.
estimated duration: 0.743039 sec
audio bytes: 131072
audio packets: 32768
bit rate: 1411200 bits per second
packet size upper bound: 4
maximum packet size: 4
audio data file offset: 80
optimized
source bit depth: F32
----

Then used Terminal afconvert -f WAVE -d LEI16 to convert it to a 16-bit .wav file. (Just cuz already in terminal and learning these new tools – assuming could have used any audio software to convert. EDIT: WRONG assumption, see below – Audacity export is different.)

New file info:

File type ID:   WAVE
Num Tracks:     1
----
Data format:     1 ch,  44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 0.743039 sec
audio bytes: 65536
audio packets: 32768
bit rate: 705600 bits per second
packet size upper bound: 2
maximum packet size: 2
audio data file offset: 4096
optimized
source bit depth: I16
----

Important clue:

audio data file offset: 4096

Essentially this offset value helped solve the issue. I wish I could extract it in Vuo. The number 4096 here apparently relates to the Apple ‘FLLR’ subchunk – listed in the Read Wave Header subcomp “File info” readout – which designates (IIUC) >4k bytes before the audio data “payload” starts.

So I try offsetting the data start byte to 4097 – works. I also noticed in the Read Wave Header “File info” readout that the “Sub-chunk 2 size” reads 4044 – related but 52 bytes off – 44 byte header + 8 bytes? So I tried setting the data start byte to 4045 and that also works. So i am a little confused why both work, still a lot I’m not getting about the numbers… (Btw, also had to rejigger the Read Wave Header subcomp to properly calculate the data section size, took a minute to get that sorted.)

Finally – success!!!

Part 2: tried a simple conversion from Audacity, since the export to .wav only exports 16-bit. (I set up a macro – now I can easily batch convert my 32-bit files to 16-bit). Terminal afinfo shows that it is different from the .wav using Apple’s afconvert, the Audacity file is presumably more “universal” (i.e., audacity does not add the “FLLR” chunk and the +4k byte padding – why oh why would Apple do that…).

And using the data file offset to set the data start byte (to 45) works:

File type ID:   WAVE
Num Tracks:     1
----
Data format:     1 ch,  44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 0.743039 sec
audio bytes: 65536
audio packets: 32768
bit rate: 705600 bits per second
packet size upper bound: 2
maximum packet size: 2
audio data file offset: 44
optimized
source bit depth: I16
----

---

Yet another doc has proved helpful in all this RIFF stuff: Google Code Archive - Long-term storage for Google Code Project Hosting. (which originated here: python - AVAudioRecorder doesn't write out proper WAV File Header - Stack Overflow ).

Notable:

Reading WAVE files properly must really begin as an exercise in locating and identifying RIFF subchunks.

And:

It is allowable to insert subchunks after the data payload.

Which gets back to @smokris’s point not to trust where chunks are. Case in point, learned today that “acidized” .wav’s – a common format for adding loop metadata readable by audio sampler synths – put their loop metadata after the audio data “payload”.

Finally…

@MartinusMagneson wrote:

If you’re not scared of some heavy nerding, you can also just get the bytes from the wav files via the Data nodes and convert the sample range from the file to the Y-values you need. That way you get straight to the data you want …

:: Well, I guess I’m learning a few things. :-0

(Ps. is drag/drop broken for adding new files to posts?)  

3DAudioWaveform.zip (218 KB)