add ambisonic subtypes

[ruuda]

Thank you for taking the time to open a pull request. This change looks good to me, I assume the magic values are correct, but I wonder, what is the meaning of these formats, do they have a meaning that needs special treatment?

For example, there are also subtypes for A-law and μ-law samples, but if we’d just map those to SampleFormat::Int and the user expects to get linear PCM, then the result will be incorrect, with no way to signal to the user that the sample format is not linear PCM. Is such a thing the case for Ambisonic, or are they really just the same as the regular variants?

I found https://www.ambisonic.net/mulchaud.html but it doesn’t mention the specific constants you added. From Wikipedia, it seems the meaning of the samples is different from linear PCM?

[aentity]

magics can also be found and verified in libsndfile https://github.com/libsndfile/libsndfile/blob/c81375f070f3c6764969a738eacded64f53a076e/src/wav.c#L121-L127

ambisonic file is spherical harmonics. each channel (4) is one of the 4 values in a Bformat sample, w, x, y, z.

my understanding is .amb files are just wav files with these guid, to let users understand further interpretation of samples is required (not simply a 4 channel file meant to play into quadrophonic speakers), for example, needs a decoder to play into stereo, or into another speaker orientation.

[ruuda]

Hmm, so what I am slightly worried about is that people will load up a file like that in a program that doesn’t know Ambisonic exists, but it succeeds because the sample format is the same, and then at best they hear garbage but at worst they destroy their speakers.

I’m not too worried about it because this format seems quite arcane, and especially if the convention is to have a different extension, I think it could be okay.

I would like to handle that better in a future API, at the very least expose a way to check what the sample format is, but right now I don’t see an easy way to do that without invasive or ad-hoc changes, so I’m going to accept it as-is.

[ruuda]

I do have one request — are you able to share such a file that you encountered in the wild (preferably with the audio data truncated to fewer than 32 samples to avoid copyright problems), to add as a test case?

[aentity]

Hello, thank you for merge. I understand your concern. however, if user loads the file, they will see 4 channels. what they do with that is up to them, like any other use of wav loader. in audacity for example, loading a wav file with this guid set does nothing, it just loads it up like a 4 channel wav file. i can press play and it will play it, and it will sound a little strange (4 channels mux to stereo), but it cannot damage anything. well let us say it cannot damage anything just as much as any other regular wav file could damage something (always lower volume first before playing new source, no matter what). and funny enough if i save this file, it will strip out that guid. it is how i "fixed" files to use with your library before this PR :) i got tired of this manual process, so i sent you this.

For files, you can listen and browse to heart content here: https://www.ambisonia.com/

it has many free and free to use samples.

if you find a file you like, free of copyright concern, send me link and i will create test case for you, if you instruct me how, thank you.

and thank you again for library.

might i also suggest in the future a update to later cargo editions (fix all warnings, deprecations, etc.), and a rustfmt run?

[ruuda]

if you find a file you like, free of copyright concern, send me link and i will create test case for you, if you instruct me how, thank you.

Any file is fine, if the data is truncated they should be very similar anyway. Another reason for truncating aside from sidestepping copyright issues is to keep the repository small and tests fast, the important part is being able to parse the header.

How to construct an example ... it depends a bit, is there a tool that generates/exports these files? That would be the best, because then we can test that Hound is compatible with a file that is written by real-world tools. If you don’t have access to such software, then we can take one of the example files that are available on https://www.ambisonia.com/, identify the start of the data chunk, truncate it to a few samples, and then in a hex editor patch the file header and the header of the data chunk to reflect the new size. That is tedious to do though.

might i also suggest in the future a update to later cargo editions (fix all warnings, deprecations, etc.), and a rustfmt run?

Yes, I know ... I’ve been planning to do a more invasive overhaul of the entire crate, because the current design (reading everything up to the start of the data when you construct a reader) is not suitable for some use cases, and I’m not happy with the current state of the master branch. I’m saying this for years now though, and I never get to it. I did make a start on it at some point in 2020. I made a new attempt yesterday triggered by this pull request, but to be very honest, I don’t expect to finish it in the next few months.

[aentity]

hello, clicking on random files this is CC, share alike: https://www.ambisonia.com/Members/pwhodges/ambisonicfile.2007-07-20.4196055721/

is it possible to have minor patch release with ambisonic guid?