Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Monkey's Audio Adds 32-bit Float Support (Read 7373 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #50 –
Thanks.  Those files have a subformat in the header that's all 0 bytes.  If I let that pass they compress fine and decompress.  Should I just make that change?  The only thing I'm checking that subformat for is if it specifies float (KSDATAFORMAT_SUBTYPE_IEEE_FLOAT).  Thanks.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #51 –
Let them pass. The files use wFormatTag 1, so not extensible and don't have SubFormat. Most of my programs handle these files correctly, including:
Audacity 2.3.3
Audition 1.5
MPC-HC 2.1.3
flac 1.4.3
WavPack 5.6.6
Spek 0.8.5
...and my software, oldsCool

The only failing software I tried is SoX:
Code: [Select]
WAVE header error: cbSize inconsistent with fmt size

Re: Monkey's Audio Adds 32-bit Float Support

Reply #53 –
Is BW64 maybe turning into a topic in itself ... ?

Until this thread I had no idea that they are apparently trying to kill off RF64. Which doesn't have that much support anyway. According to https://adm.ebu.io/reference/excursions/bw64_and_adm.html a couple of more chunk types are supposed to handle the new content. (Hm, one of them is already in BWF.) And part of the purpose is to open for ambisonics and the like, which isn't reasonably described in your usual channel allocation map.

Which potentially suggests that a lossless codec should actually read this and decide whether their own channel allocation scheme can accommodate it, and reject if not?

Re: Monkey's Audio Adds 32-bit Float Support

Reply #55 –
Quote from: bennetng on
BW64 seems rather young, this link has specs:
https://www.itu.int/rec/R-REC-BS.2088/en

Wave64: All I can find are scattered information instead of official specs from the inventor (Sonic Foundry or Sony).
I have an old spec for Wave64 that I got somewhere. I googled a couple lines in there and found it sitting here, but I'd grab it while you can (that URL does not sound like anything permanent!)

Martin Leese is (or was) heavily involved in Ambisonics development.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #56 –
Nice info, thanks :)

Re: Monkey's Audio Adds 32-bit Float Support

Reply #57 –
Quote from: bennetng on
One should also consider not every DAW/player/renderer etc. support everything BW64 offers.
Yeah, point. I don't know how DAW software and format plugins work (like, do they just pass the file on and if <codec-plugin-in-question> doesn't support it then trouble?), but if the software cannot handle anything but "standard multichannel" but still thinks it is a good idea to go for BW64 ...

Although https://en.wikipedia.org/wiki/Comparison_of_digital_audio_editors#File_format_support doesn't look much like that is the case. Surely incomplete table, but for what a text search is worth:
* BW64: no hits
* RF64: one hit
* BWF: 2 hits
* W64: 8 hits, plus one "WAV64", I don't know if that is intended to be the same
* CAF: 6 hits
* Monkey's: 4 including one "APE" hit
* WavPack: 2

Again, incomplete table I guess - but does it look like W64 has taken the lion's share of the > 4GB segment?

Re: Monkey's Audio Adds 32-bit Float Support

Reply #58 –
The input file is static, the changing parts are on the decoding/playback/streaming side. Codec developers cannot predict how good or bad third party software will support a format in future. As long as the input file is completely archived, any feature update on third party editing/playback/streaming apps should not affect the native encoder.

...and yes, the Wikipedia article is rather incomplete, for example these software support RF64:
https://manual.audacityteam.org/man/other_uncompressed_files_export_options.html
https://helpx.adobe.com/audition/using/saving-exporting-files1.html
https://legacy.cakewalk.com/Documentation?product=CakewalkSonar&language=3&help=Recording.32.html
https://steinberg.help/wavelab_pro/v10/en/wavelab/topics/audio_files_editing/supported_file_formats_c.html
https://steinberg.help/cubase_pro/v10.5/en/cubase_nuendo/topics/preferences/preferences_record_audio_r.html
https://www.vegascreativesoftware.com/fileadmin/user_upload/business_solutions/audio_production/pdf/i_9a4897/SEQUOIA_ONE_PRO_COMPARISON_JUNE_22_en.pdf

BW64:
https://ear-production-suite.ebu.io/

Re: Monkey's Audio Adds 32-bit Float Support

Reply #59 –
Quote from: Porcus on
@bennetng : your file reaper-bw64.wav is not recognized by neither MediaInfo, VLC, WavPack nor foobar2000 ... ?
(SMPlayer handles it.)
I was blissfully unaware of BW64 until now, thanks guys!  :D

It was easy enough to add support in WavPack to accept the BW64 fourcc and it worked with the Reaper file that had it. I saw that Reaper set the "sampleCount" field in the <ds64> chunk, which it’s really not supposed to do (it’s called “dummy” now and the spec says zero is the correct value), but I currently require that to be set correctly so it worked fine, but I’ll have to make that optional for BW64.

And they do have a whole lot of complex channel assignment stuff, and essentially say that setting the WAV_FORMAT_EXTENSIBLE data is no longer allowed, which means no more "channelMask". At least for now I won’t be handling any of that (other than storing it verbatim, obviously). I spent several weeks providing for many of the extended channel information options in CAF (including complex additions to the WavPack format itself to accommodate CAF files that are “out-of-order” and creating a bunch of new channel assignments) and for what? I’m pretty confident it’s never been used and now CAF is fading away. This time I’ll be more “wait and see” (I haven’t even gotten a report of someone trying a BW64 with WavPack).

I did find one problem with those opera files from soundsonline. They have an extended format tag (40 bytes) but they set cbSize and the extended info to zero. I was mistakenly getting the zeroed channel mask out of there based on the size of the format tag (despite cbSize being zero) and so those show up as “unassigned speakers” instead of “stereo”. That’s an easy fix.

Thanks again both of you for keeping on top of all this and providing test files!

Re: Monkey's Audio Adds 32-bit Float Support

Reply #60 –
Quote from: bryant on
It was easy enough to add support in WavPack to accept the BW64 fourcc and it worked with the Reaper file that had it. I saw that Reaper set the "sampleCount" field in the <ds64> chunk, which it’s really not supposed to do (it’s called “dummy” now and the spec says zero is the correct value), but I currently require that to be set correctly so it worked fine, but I’ll have to make that optional for BW64.

And they do have a whole lot of complex channel assignment stuff, and essentially say that setting the WAV_FORMAT_EXTENSIBLE data is no longer allowed, which means no more "channelMask". At least for now I won’t be handling any of that (other than storing it verbatim, obviously).

Out of curiosity: That is enough for the relevant DAWs? They likely need to access and manipulate the original file's chunks so much that they shouldn't even care what the .wv / .ape calls the channels?

 
Quote from: bryant on
(I haven’t even gotten a report of someone trying a BW64 with WavPack).

Yeah I didn't get that far. As reporting it, I mean ;D

Re: Monkey's Audio Adds 32-bit Float Support

Reply #61 –
Quote from: Porcus on
Quote from: bryant on
It was easy enough to add support in WavPack to accept the BW64 fourcc and it worked with the Reaper file that had it. I saw that Reaper set the "sampleCount" field in the <ds64> chunk, which it’s really not supposed to do (it’s called “dummy” now and the spec says zero is the correct value), but I currently require that to be set correctly so it worked fine, but I’ll have to make that optional for BW64.

And they do have a whole lot of complex channel assignment stuff, and essentially say that setting the WAV_FORMAT_EXTENSIBLE data is no longer allowed, which means no more "channelMask". At least for now I won’t be handling any of that (other than storing it verbatim, obviously).

Out of curiosity: That is enough for the relevant DAWs? They likely need to access and manipulate the original file's chunks so much that they shouldn't even care what the .wv / .ape calls the channels?
Yeah, libwavpack allows the application to access the original headers, which they must know how to parse anyway if they can handle a BW64. That's how Reaper does it and how I did it in Audition.

Of course, it would be nice if the files retained some sort of rationality with respect to channel assignment so they could be played with other software, especially if they're, for example, just stereo. But I'm not going to go to the lengths I did with CAF (like reordering channels if they aren't in MS order) until I see that this is actually going to be used (I need to at least see a <chna> chunk in a file not created by the ITU).

Quote

Quote from: bryant on
(I haven’t even gotten a report of someone trying a BW64 with WavPack).

Yeah I didn't get that far. As reporting it, I mean ;D
Well, I'm glad I could save you the trouble!  ;D

Re: Monkey's Audio Adds 32-bit Float Support

Reply #63 –
Quote from: bennetng on
NHK's use of BW64 for "Semi-live production":
https://www.nhk.or.jp/strl/english/publica/bt/92/pdf/bt92.pdf
Interesting article, thanks!

One thing I noticed in the BW64 spec is that the channel assignments can actually change during a file (with the xml ADM file controlling it). Not sure how that's going to work, even if I try to implement the <chna> chunk.

But preserving the original file will provide rudimentary support to start.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #64 –
It isn't that outrageous in broadcasts. Like, interrupting with commercials? They might not be in the same channel count or allocation, even if one is sticking to the "channel-based" setup.

I didn't dig into the BW64 spec, but if it can change not only the allocation but also the number of channels and also switch between the "channel-based" / "object-based" / "scene-based" setups, you are facing quite a beast in the end. File chaining next?

Re: Monkey's Audio Adds 32-bit Float Support

Reply #65 –
Quote from: Porcus on
I didn't dig into the BW64 spec, but if it can change not only the allocation but also the number of channels and also switch between the "channel-based" / "object-based" / "scene-based" setups, you are facing quite a beast in the end. File chaining next?
I didn't see anything about changing the number of channels; that would be a beast! It would make basic operations like seeking and compression impossible without parsing the xml ADM file (which can be gzip'd).

If the number of active channels changes (which, like you say, makes perfect sense) then the unused ones would be silenced, which points to another benefit of applying compression.
 

Re: Monkey's Audio Adds 32-bit Float Support

Reply #66 –
There is a fine line between muting/"including then disabling" channels and reducing the number. Quite sure that some playback chains will scream at one or the other. Like, you have a 3.1 system fed a signal that identifies as 5.1 but with two silent channels?
Mentioning it because FLAC actually can change channel count mid-stream - the format facilitates streaming to the extent that a player can start decoding without knowing the file headers. But then one is constrained to the channel allocations that once were laid down in the format, and that means you cannot get 2.1, 3.1 or 4.1 without defining 5.1 and muting streams. Well you can at the beginning of the file, but if then you are in for a non-standard solution if you change channel count.

Anyway, a format capped at eight channels isn't going to make it here. But I've seen "immersive" files like 7.1.4 been sold with download options being 12-channel file (WAVE only), or 8 channel file + 4 channel file, or twelve individual WAVE files - that's what they get for refusing any codec with "k" in it.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #67 –
Quote from: Porcus on
File chaining next?
File chaining is not a new thing. SoundFont (.sf2) and Downloadable Sounds (.dls) are both RIFF audio formats doing this.

Windows system folder has gm.dls:
https://www.virustotal.com/gui/file/3229b09b9d7d9f3f4793b0d9b34fe6abc75cfa4a2503c0c90f43ff651ba7f2c0

There are many Googlable free SoundFonts too, with bigger file sizes, like this:
https://sites.google.com/site/soundfonts4u/

The BASS audio library supports both lossless and lossy SoundFont compression via different codecs.
https://www.un4seen.com/

Attached the SoundFont specs.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #69 –
BW64 still relies on the legacy fmt and data chunks, so still interleaving channel-based audio data. Chaining files would require one fmt and one data chunk per file with independent sample rate, bit-depth, data format (e.g. integer vs float) as so on, and BW64 is not doing it.

Another static thing is hardware capability. A 7.1 speaker system is not possible to suddenly transform to a 22.2 one, it is only possible via the object-based simulation. When the physical channel limit is known, there is no need to create or destroy any audio channel to the hardware on the fly, because the channels are simulated via panning, muting, duplicating and dynamic mixing among the known final channel count to the output and these are not the audio file archiver handles. The same way a SoundFont archiver is not responsible for the jobs of synthesizers and sequencers.

Changing the channel count to hardware won't work even when there is no compression, unless the hardware is specifically designed to handle this, or the playback software needs to understand the incoming ADM metadata and apply appropriate object-to-channel processing.

Re: Monkey's Audio Adds 32-bit Float Support

Reply #70 –
This is turning into a lot of text on three small words at the end of reply #64, but I was not talking about chained source files.
Rather, "the codecs in question" would be the compressed formats (like .ape or .wv, which is not to say it would fit any of them).

What I was hinting at - "not even at 'suggestion' status" - would be that if a file format (.ape or .wv) does not allow for audio to change mid-stream, then the file format (not the source!) could be extended by allowing "file concatenation". Possibly with the appropriate constraints like "APEv2 only allowed at the end of the new full file", and thinking it over there could very well be more constraints like "source file headers in first segment only", "source file footers only in [first|last] segment only" - but I didn't think that far. It was a light-hearted remark.

Not the most stupid of ideas, but I don't know if it is feasible for [insert format and its release philosophy here].