date:20210523


-


The traditional argument for N3D against SN3D is that N3D would force the

 omni (W) channel down because the higher order signals have higher gain,

 and that would reduce the available dynamic range.



 That is true for a single encoded source, but not for a complex mix of

 sources in all directions. And if you think about the gain structure of

 a complete system (including decoding to speaker signals), that is how

 it should be: a single source will be reproduced by only a few speakers,

 so it can never have the same SPL as a complex surround signal at maximum

 level. Since W represents the mono mix, its maximum level for a single

 source *should* be lower. So the rational choice would be N3D. In order

 to obtain the same headroom using SN3D, the overall level must be lower,

 with additional gain at the receiving end to compensate. This completely

 negates any S/N advantage that SN3D is supposed to have.



 I actually mentioned this in the meetings that resulted in the Ambix

 format, but lost the vote.


- - -

No, you did not lose all the vote 😉: 

https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2094-1-201706-I!!PDF-E.pdf

Table 3 - 7...

Best,

Stefan

- - - -


Ciao,



 --

 FA



 ___

 Sursound mailing list

  
surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -  
unsubscribe here, edit account or options, view archives and so on.


- Fim da mensagem de Fons Adriaensen  -
-- next part --
An HTML attachment was scrubbed...
URL: 

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))

Depends how you see this, because in practice the home system of Atmos  
is confined to two rings of speakers, and so you are confined to some  
vertical perspective which is quite reduced. (And the cinema system  
might struggle to pan positions between ground "bed" and the ceiling...)


I don't think that the current Atmos home system (E-AC3 + JOC) does  
also stereo + objects. (They do this in AC-4, probably.)


Stefan

- Mensagem de Fons Adriaensen  -

 Data: Sun, 23 May 2021 22:50:28 +0200

 De: Fons Adriaensen 


On Sun, May 23, 2021 at 06:36:51PM +0100, Stefan Schreiber wrote:


Netflix streams Dolby Atmos at 768 kbit/s. (if available, so this is max.

 bitrate)


Atmos can use any mix of (fixed position) channels and (moving) objects.

 So it can be as simple as 5.0 or even stereo with a few objects for effects.



 In terms of required channel count (for distribution) it's actually a very

 effective format, for almost all content it will require less channels than

 high order Ambisonics.



 --

 FA



 ___

 Sursound mailing list

  
surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -  
unsubscribe here, edit account or options, view archives and so on.


- Fim da mensagem de Fons Adriaensen  -
-- next part --
An HTML attachment was scrubbed...
URL: 

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)


Le 2021-05-23 à 18 h 30, Marc Lavallée a écrit :


In include/FLAC/format.h, I changed  FLAC__MAX_CHANNELS from 8u to 128u

In src/libFLAC/format.c, I changed 
FLAC__STREAM_METADATA_STREAMINFO_CHANNELS_LEN from 3 to 8.


The code compiles, but encoding more than 8 channels fails (I tried 
with 19). It still works with 8.


Oops, I lied...

Changing FLAC__STREAM_METADATA_STREAMINFO_CHANNELS_LEN to more than 3 
make flac unusable.


Marc

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)


Le 2021-05-23 à 16 h 58, Martin Leese a écrit :


Extending FLAC to more than eight channels
has been discussed in the past.For
example, look in the sursound archives for this
long post by me:
 Subject: Re: [Sursound] octofile release
 Date: Mon Jul 30 22:30:42 EDT 2018

Here is a link:
https://mail.music.vt.edu/mailman/private/sursound/2018-July/049694.html



The simple problem is that the field in the
header used for the number of channels is
only three bits.


In include/FLAC/format.h, I changed  FLAC__MAX_CHANNELS from 8u to 128u

In src/libFLAC/format.c, I changed 
FLAC__STREAM_METADATA_STREAMINFO_CHANNELS_LEN from 3 to 8.

The code compiles, but encoding more than 8 channels fails (I tried with 19). 
It still works with 8.

It's a question for the FLAC dev mailing list

Marc

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/ec3a6305/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)

Provided that FLAC is really kind of inextensible:

Could you not define a "new" FLAC II format, now being reasonably defined?

In the best case the FLAC II decoder can still read the FLAC "legacy"
format, and things would work.

It is not pretty, but could be done. (In case there is some demand
for, of course.)

I actually don't see such a big difference to the "well-formed FLAC
case", because you would need a new decoder anyway. Or am I wrong on
this?

Best regards

Stefan

(P.S.: Not giving up on this so fastly... )

- Mensagem de Fons Adriaensen -

Data: Sun, 23 May 2021 22:40:26 +0200

On Sun, May 23, 2021 at 01:10:21PM -0600, Martin Leese wrote:

Extending FLAC to more than eight channels

has been discussed in the past. For

example, look in the sursound archives for this

long post by me:

Subject: Re: [Sursound] octofile release

Date: Mon Jul 30 22:30:42 EDT 2018

It is not possible, except by using multiple

FLAC streams in a single container.

Does this 8 channel limit exist just because only 3 bits are reserved for

the number of channels in the STREAMINFO block, or is it a fundamental

limit of the algorithm ? I suspect it's the former.

Apparently whoever defined that format was thinking that even a single

byte would be a terrible waste of bits. Same for the maximum size (in

frames) which is 36 bits. Rounding that up to 5 bytes would again have

been a terrible waste of superexpensive bits. I wonder how that passed

any serious review...

Ciao,

___

Sursound mailing list

surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -
unsubscribe here, edit account or options, view archives and so on.

-- next part --
An HTML attachment was scrubbed...
URL:
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/2a0145f9/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))


Le 2021-05-23 à 16 h 50, Fons Adriaensen a écrit :

Atmos can use any mix of (fixed position) channels and (moving) objects.
So it can be as simple as 5.0 or even stereo with a few objects for effects.

In terms of required channel count (for distribution) it's actually a very
effective format, for almost all content it will require less channels than
high order Ambisonics.


Because Dolby Atmos is not free (as in speech), some people (like me) 
cannot experience it (and are not feeling like missing something); age 
and demographics is also a factor: target audiences are gamers, have the 
latest gadgets, phones and cars, enjoy new commercial films, television, 
sport, Netflix, etc...


The official consumer propaganda is not a good explanation. Wikipedia 
helps a bit. For example, is using stereo (for some ambiance) with 
objects and DSP more effective than 3rd order Ambisonics? Is the 5.1 
"Dolby Atmos" format like a generic 5.1 format, but with extra objects? 
When all we read it "better", "24bit", "object based" and other 
buzzwords, it's very difficult to understand.


Dolby Atmos looks like it's using a mix of available audio 
spatialization techniques, and a set of decoding techniques for a range 
of target devices and speaker layouts, made by and for a national 
industry (no need to mention which one).


Marc

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))

Correction:

The traditional argument for SN3D and against N3D ...


___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))

On Sun, May 23, 2021 at 04:57:30PM +0100, Stefan Schreiber wrote:

> (If ACN/SN3D in the above sense adds anything to Jerôme Daniel’s thesis of
> 2001 is another question.

What do you mean by 'adding anything to the thesis' ??

> ACN/N3D is also in wide use, supported by Mpeg, by ITU standards, and
> still others.

The traditional argument for N3D against SN3D is that N3D would force the
omni (W) channel down because the higher order signals have higher gain,
and that would reduce the available dynamic range.

That is true for a single encoded source, but not for a complex mix of
sources in all directions. And if you think about the gain structure of
a complete system (including decoding to speaker signals), that is how
it should be: a single source will be reproduced by only a few speakers,
so it can never have the same SPL as a complex surround signal at maximum
level. Since W represents the mono mix, its maximum level for a single
source *should* be lower. So the rational choice would be N3D. In order
to obtain the same headroom using SN3D, the overall level must be lower,
with additional gain at the receiving end to compensate. This completely
negates any S/N advantage that SN3D is supposed to have.

I actually mentioned this in the meetings that resulted in the Ambix
format, but lost the vote.

Ciao,

-- 
FA

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)

2021-05-23 Thread Martin Leese

On 5/23/21, Martin Leese  wrote:

> Extending FLAC to more than eight channels
> has been discussed in the past.For
> example, look in the sursound archives for this
> long post by me:
> Subject: Re: [Sursound] octofile release
> Date: Mon Jul 30 22:30:42 EDT 2018

Here is a link:
https://mail.music.vt.edu/mailman/private/sursound/2018-July/049694.html

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))

On Sun, May 23, 2021 at 06:36:51PM +0100, Stefan Schreiber wrote:

> Netflix streams Dolby Atmos at 768 kbit/s. (if available, so this is max.
> bitrate)

Atmos can use any mix of (fixed position) channels and (moving) objects.
So it can be as simple as 5.0 or even stereo with a few objects for effects.

In terms of required channel count (for distribution) it's actually a very
effective format, for almost all content it will require less channels than
high order Ambisonics.

-- 
FA

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)

On Sun, May 23, 2021 at 01:10:21PM -0600, Martin Leese wrote:

> Extending FLAC to more than eight channels
> has been discussed in the past.For
> example, look in the sursound archives for this
> long post by me:
> Subject: Re: [Sursound] octofile release
> Date: Mon Jul 30 22:30:42 EDT 2018
> 
> It is not possible, except by using multiple
> FLAC streams in a single container.

Does this 8 channel limit exist just because only 3 bits are reserved for
the number of channels in the STREAMINFO block, or is it a fundamental
limit of the algorithm ? I suspect it's the former.

Apparently whoever defined that format was thinking that even a single
byte would be a terrible waste of bits. Same for the maximum size (in
frames) which is 36 bits. Rounding that up to 5 bytes would again have
been a terrible waste of superexpensive bits. I wonder how that passed
any serious review...

Ciao,

-- 
FA

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)

The Mp4 container should work just fine with multiple audio streams 
(even in FLAC).


8 channels for 2nd order HOA (with one vertical component missing) is 
good enough, and that could be why it's a format used for VR audio. But 
some audio enthousiasts could enjoy streams in 3rd order (and more).


If streaming services can bring 4K video streams to masses, it'd be 
possible to stream 16 channels (and more); bandwidth is an issue for 
live streams, a bit less with podcasts.


Streaming with multiple tracks would allow the scaling of ambisonics 
resolution; I wonder if it already exists...


Marc

Le 2021-05-23 à 15 h 10, Martin Leese a écrit :

Stefan Schreiber wrote:


It would be relatively easy to extend FLAC to more than 8 channels.

(To cover ?exotic? audio formats such as 5.1.4, HOA, and a plentitude
of audio object standards.)

Extending FLAC to more than eight channels
has been discussed in the past.For
example, look in the sursound archives for this
long post by me:
 Subject: Re: [Sursound] octofile release
 Date: Mon Jul 30 22:30:42 EDT 2018

It is not possible, except by using multiple
FLAC streams in a single container.

Regards,
Martin

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)

2021-05-23 Thread Martin Leese

Stefan Schreiber wrote:

> It would be relatively easy to extend FLAC to more than 8 channels.
>
> (To cover ?exotic? audio formats such as 5.1.4, HOA, and a plentitude
> of audio object standards.)

Extending FLAC to more than eight channels
has been discussed in the past.For
example, look in the sursound archives for this
long post by me:
Subject: Re: [Sursound] octofile release
Date: Mon Jul 30 22:30:42 EDT 2018

It is not possible, except by using multiple
FLAC streams in a single container.

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

[Sursound] distribution codecs (was Re: Matroska)


Le 2021-05-23 à 13 h 36, Stefan Schreiber a écrit :

I know for sure that some companies would not like to spend 1 Mbit/s 
bitrate (or even more) on some HOA track at 3rd or 4th order. (I am 
not making this up.)


An interesting option (to me) is to stream in lossless FOA and add 
optional resolution with some parametric decoding (at the listening 
side). I noticed that FOA sound better with a lossless codec (with or 
without parametric decoding). I may have a strong bias for "lossless" 
(and/or that I don't master the art of audio compression). HOA is nice, 
but more channels doesn't always mean the results will be (a lot) better.


Netflix streams Dolby Atmos at 768 kbit/s. (if available, so this is 
max. bitrate)


This is for a compressed 5.1 stream at 24 bit resolution, which is 
marketing; a well produced mix doesn't have much to gain from a 24 bit 
target. 48Khz is also used as marketing; 32Khz can be enough to bring a 
decent experience (unless Netflix is streaming for dogs). The ".1 
channel" is useless in most domestic situations; good bass management 
can extract enough low frequency information from available channels. 
And 5.1 as a native format (for reproduction on actual 5.1 systems, not 
"sound bars") is probably for a minority of listeners.


A 3-channel 16bit/32Khz Ambisonics FLAC streams requires 750 kb/s. Of 
course, numbers like this would scare any consumer who want "more" (from 
branded solutions), but in A/B tests (and situations like head-tracked 
binaural rendering), this simple version probably works just fine. 
Disclaimer: I'm not young, so I may not have the best ears.


Distribution though Internet brings a lot of advantages, so we can be 
creative with available codecs and formats.


Marc

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))


I don’t want to argue too much, especially since we often agree.

“Not losing information” is of course essential for production and archiving.

I know for sure that some companies would not like to spend 1 Mbit/s  
bitrate (or even more) on some HOA track at 3rd or 4th order. (I am  
not making this up.)


Netflix streams Dolby Atmos at 768 kbit/s. (if available, so this is  
max. bitrate)


Just to compare...

“Open HOA” is possible, agreed. (see above)

Best,

Stefan

- Mensagem de Marc Lavallée  -

 Data: Sun, 23 May 2021 12:43:37 -0400

 De: Marc Lavallée 

 Assunto: Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was:  
Re: Ambix files)))


 Para: Surround Sound discussion group 


Le 2021-05-23 à 11 h 57, Stefan Schreiber a écrit :

In this sense independent from the actual source format. (Which  
does not have to be .caf, as Fons already wrote.)


Fons also wrote about the several advantages of CAF.

- In my estimation you need standardization rather for the  
distribution/CE/application side than for production.


I'm less concerned by distribution. Not loosing information is more  
important; standardization can help, but I would not bet too much on  
it. Being creative with good documentation can be as good as trying  
to fit everything in elusive standards. Using the good parts of  
standards is already difficult.


- I don’t think that (currently) any other lossless codec would  
have a good chance to be adopted in browsers, so there is (“maybe”)  
a problem with real-world music streaming.


We'll see. The "real world" is controlled by commerce. We can  
accept, adapt, propose alternatives, or do what we want when we can.




 Marc









 ___

 Sursound mailing list

  
surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -  
unsubscribe here, edit account or options, view archives and so on.


- Fim da mensagem de Marc Lavallée  -
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/67d0df88/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))


Le 2021-05-23 à 11 h 57, Stefan Schreiber a écrit :

> In this sense independent from the actual source format. (Which does 
not have to be .caf, as Fons already wrote.)


Fons also wrote about the several advantages of CAF.

> - In my estimation you need standardization rather for the 
distribution/CE/application side than for production.


I'm less concerned by distribution. Not loosing information is more 
important; standardization can help, but I would not bet too much on it. 
Being creative with good documentation can be as good as trying to fit 
everything in elusive standards. Using the good parts of standards is 
already difficult.


> - I don’t think that (currently) any other lossless codec would have 
a good chance to be adopted in browsers, so there is (“maybe”) a problem 
with real-world music streaming.


We'll see. The "real world" is controlled by commerce. We can accept, 
adapt, propose alternatives, or do what we want when we can.


Marc




___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))

A few comments:

- If Ambix is a “standard”, than probably as Ambix convention. (Which
is ACN channel ordering and SN3D normalization.)

In this sense independent from the actual source format. (Which does
not have to be .caf, as Fons already wrote.)

(If ACN/SN3D in the above sense adds anything to Jerôme Daniel’s
thesis of 2001 is another question. ACN/N3D is also in wide use,
supported by Mpeg, by ITU standards, and still others. Conversion is
trivial, so I don’t see a special problem here.)

- In my estimation you need standardization rather for the
distribution/CE/application side than for production. (Which can be
more flexible. You prove this, because “Matroskambix” is the probably
the production side... ;-)

- That Flac < is > widely supported you can see here:

https://support.tidal.com/hc/en-us/articles/203055911-High-Fidelity-HiFi-Sound

- Apple Lossless will use ALAC, which is just fine for the Apple
ecosystem. < g >

- I don’t think that (currently) any other lossless codec would have a
good chance to be adopted in browsers, so there is (“maybe”) a problem
with real-world music streaming.

Best,

Stefan

- Mensagem de Marc Lavallée -

Data: Sun, 23 May 2021 11:24:17 -0400

De: Marc Lavallée

Assunto: [Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re:
Ambix files)))

Para: Surround Sound discussion group

Le 2021-05-23 à 10 h 22, Stefan Schreiber a écrit :

“So using the Ambix format in a CAF container with ALAC compression
is a good choice.”

Seriously: Is a good choice for what?

Good for production, because Ambix is a recognized format, and maybe
a de-facto standard (without ALAC because it's not a working
solution). Distribution formats are at the end of the chain (and
moving targets), so the first concern is production.

What I'm looking for is a simple container for capture, production
and archival (but not for distribution). Ambix can be used to
include custom data for production and archival. Because Ambix is
limited to audio I'm also considering using the Matroska container;
but containers are not easy to configure to include special tracks
(or "chunks"), in order to interleave streams of continuous data
(GPS, orientation, cues, etc).

Compression is nice for storage (and capture) but it's not
essential (except in some capture situations). WavPack already have
more features than FLAC, as a compression format and container. It'd
be nice if WavPack could be used with the CAF container (as
suggested in the 2011 Ambix article), like with the Matroska
container.

Neither WavPack or ALAC are universally accepted formats, so you
could ask if “extended Flac” (normal adapation to changing
realities requires more than 8 channels) could be a better choice
in the long-term.

Maybe? But WavPack is already a better fit than FLAC for Ambisonics
use cases (for example: Zylia chose it).

What I'd like is a "Matroskambix" or "Ambimkv" format! :-)

I also wonder if scientific formats like HDF5 could be used...

Marc

___

Sursound mailing list

surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -
unsubscribe here, edit account or options, view archives and so on.

- Fim da mensagem de Marc Lavallée -
-- next part --
An HTML attachment was scrubbed...
URL:
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/5bf1bbc8/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit
account or options, view archives and so on.

[Sursound] Matroska (was: ALAC (was Re: WavPack (was: Re: Ambix files)))


Le 2021-05-23 à 10 h 22, Stefan Schreiber a écrit :

> “So using the Ambix format in a CAF container with ALAC compression 
is a good choice.”

> Seriously: Is a good choice for what?

Good for production, because Ambix is a recognized format, and maybe a 
de-facto standard (without ALAC because it's not a working solution). 
Distribution formats are at the end of the chain (and moving targets), 
so the first concern is production.


What I'm looking for is a simple container for capture, production and 
archival (but not for distribution). Ambix can be used to include custom 
data for production and archival. Because Ambix is limited to audio I'm 
also considering using the Matroska container; but containers are not 
easy to configure to include special tracks (or "chunks"), in order to 
interleave streams of continuous data (GPS, orientation, cues, etc).


Compression is nice for storage (and capture) but it's not essential 
(except in some capture situations). WavPack already have more features 
than FLAC, as a compression format and container. It'd be nice if 
WavPack could be used with the CAF container (as suggested in the 2011 
Ambix article), like with the Matroska container.


> Neither WavPack or ALAC are universally accepted formats, so you 
could ask if “extended Flac” (normal adapation to changing realities 
requires more than 8 channels) could be a better choice in the long-term.


Maybe? But WavPack is already a better fit than FLAC for Ambisonics use 
cases (for example: Zylia chose it).


What I'd like is a "Matroskambix" or "Ambimkv" format! :-)

I also wonder if scientific formats like HDF5 could be used...

Marc

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] ALAC (was Re: WavPack (was: Re: Ambix files))

 edit account or options, view archives and so on.


- Fim da mensagem de Marc Lavallée  -
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/a75ccb44/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)

2021-05-23 Thread Bo-Erik Sandholm

That was a lot of information, I  was only thinking of distribution to
end-users on the web.

It would save a bit of volume in comparison to wav.


This is the current state of ohti,
We are to add more buttons for routing of mixed order Ambisonics, the
channel routing can be edited before playback.
I am waiting for Roger to fix it, but he has just bought a new condinium...

http://www.ohti.xyz/2021/original.html



Den sön 23 maj 2021 12:38Fons Adriaensen  skrev:

> On Sat, May 22, 2021 at 06:15:48PM -0400, Marc Lavallée wrote:
>
> > In the document, "Universal Ambisonic" is described to work with WavPack.
>
> "Universal Ambisonic" is as dead as can be, and that's probable the
> best that could happen to it. It was precisely a desire to get rid
> of ill-conceived 'standards' like this that motivated the design of
> the Ambix format. Which is also what everybody uses today.
>
> As an audio file format Wavpack is rather primitive. It could be
> useful as a format for content delivery to the end user, but for
> production it is pretty useless.
>
> AFAIK, you can convert .wav, .caf and others to Wavpack and back
> again, but only the audio data is preserved. Both WAVEX and CAF
> support a lot of other data as well.
>
> Wavpack was considered by the Ambix designers as a way to cater
> for unused channels (like for horizontal-only AMB). These would
> simply be set to all zeros and compressed to only a few bytes.
>
> But the matrix based method was chosen in the end as a better
> alternative that also offered other functionality.
>
> The reason why CAF was chosen was that it was (and still is) the
> cleanest and most versatile format available.
>
> CAF has several advantages:
>
> * 64-bit filesize, no problem with long multichannel files exceeding
>   the size limit.
>
> * Support of 'user' extensions. CAF is a 'chunked format' (like WAVEX),
>   and it also supports UUID [1] chunks, extensions that are identified
>   using a 128-bit unique identifier. These can be used without needing
>   approval or registration by Apple. Any software that doesn't know
>   how to interpret a particular UUID chunk should just ignore it.
>   Thus users can extend the format in a way that is future proof and
>   that will never be in conflict with other extensions. This is how
>   the Ambix 'extended format' is implemented and why it requires CAF.
>
> * No history of unofficial variations and extensions with all the
>   resulting fragility.
>
> Now compare that to what happened with the WAV format. The original
> WAV specs where quite ambiguous in some respects, and also lacked
> functionality. So various unofficial and mutually incompatible
> vendor extensions started to appear, and pretty soon a .wav file
> created by software X could not be used by software Y.
> More than 20 years ago Microsoft decided the clean up the resulting
> mess and created the WAVEX format. Since then, every .wav file that
> has more than 2 channels or uses more then 16 bit resolution has to
> use the WAVEX format. But there are still a lot of defective WAV
> files around, and WAVEX has no way to add UUID chunks as in the
> CAF format (they could be added easily, but that has not happened).
>
>
> Ciao,
>
>
> [1] <https://en.wikipedia.org/wiki/Universally_unique_identifier>
>
> --
> FA
>
> ___
> Sursound mailing list
> Sursound@music.vt.edu
> https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here,
> edit account or options, view archives and so on.
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/800f2540/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] ALAC (was Re: WavPack (was: Re: Ambix files))


You're so right (as always)...

It's documented here: 
https://github.com/macosforge/alac/blob/master/ReadMe.txt


So, Ambix with a CAF container as a production format.

WavPack is still valuable (at least for my use cases).

Marc

Le 2021-05-23 à 09 h 43, Fons Adriaensen a écrit :

On Sun, May 23, 2021 at 09:15:55AM -0400, Marc Lavallée wrote:


I assumed that ALAC compression is for Apple-only devices, but it works on
other platforms as well, and a quick test shows that ALAC can be a bit more
efficient than WavPack (for file size, no idea about CPU usage).

So using the Ambix format in a CAF container with ALAC compression is a good
choice.

ALAC is limited to 8 channels, and each of the possible channel counts is
associated with a particular set of speaker channels, not with Ambinsonic
signals. It's again a delivery format and not suited to production use.

Ciao,


___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)


It would be relatively easy to extend FLAC to more than 8 channels.

(To cover “exotic” audio formats such as 5.1.4, HOA, and a plentitude  
of audio object standards.)


Best,

Stefan

- Mensagem de Bo-Erik Sandholm  -

 Data: Sun, 23 May 2021 10:49:57 +0200


https://hydrogenaud.io/index.php?topic=119143.0



 Quick google gives me a the impression it could be made to work on many

 platforms.

 It is better than flac for Ambisonics due to the 8 channel limit in flac.



 Bosse



 Den sön 23 maj 2021 00:16Marc Lavallée  skrev:


Le 21-05-22 à 06 h 21, Fons Adriaensen a écrit :

 So all you need is a library to read/write .wav and/or .caf files,

 e.g. libsndfile.

 Maybe WavPack could be promoted for Ambisonics (and Ambix)? There's

 preliminary support for (lossless) WavPack in libsndfile, not yet merged

 in the official repo; I successfully tried it yesterday evening. There's

 already support in FFMPEG and Gstreamer.



 A document describing this can be found at

 <

  
https://www.researchgate.net/publication/266602800_AMBIX_-A_SUGGESTED_AMBISONICS_FORMAT




 In the document, "Universal Ambisonic" is described to work with WavPack.

 For more info:



  
http://web.archive.org/web/20131219123618/http://soundofspace.com/static/make_ua_file


 http://decoy.iki.fi/dsound/ambisonic/motherlode/source/ua09.pdf



 Marc

 ___

 Sursound mailing list

 Sursound@music.vt.edu

 https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here,

 edit account or options, view archives and so on.


-- next part --

 An HTML attachment was scrubbed...

 URL:  
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/03c3406b/attachment.htm>


 ___

 Sursound mailing list

  
surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -  
unsubscribe here, edit account or options, view archives and so on.


- Fim da mensagem de Bo-Erik Sandholm  -
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/e3daf084/attachment.htm>
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] ALAC (was Re: WavPack (was: Re: Ambix files))

On Sun, May 23, 2021 at 09:15:55AM -0400, Marc Lavallée wrote:

> I assumed that ALAC compression is for Apple-only devices, but it works on
> other platforms as well, and a quick test shows that ALAC can be a bit more
> efficient than WavPack (for file size, no idea about CPU usage).
> 
> So using the Ambix format in a CAF container with ALAC compression is a good
> choice.

ALAC is limited to 8 channels, and each of the possible channel counts is
associated with a particular set of speaker channels, not with Ambinsonic
signals. It's again a delivery format and not suited to production use.

Ciao,

-- 
FA

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

[Sursound] ALAC (was Re: WavPack (was: Re: Ambix files))


Fons, thanks for the precisions.

My question should have been "why CAF"?

I was more concerned by lossless audio compression, support for multiple 
channels, and file size.


In 
https://www.researchgate.net/publication/266602800_AMBIX_-A_SUGGESTED_AMBISONICS_FORMAT, 
WavPack is mentioned as a possible compression codec for the CAF format. 
At the time of publication (July 2011), the Apple ALAC compression codec 
was not officially released, but it was a 7 years old codec so I wonder 
why there's no mention of it; maybe at the time, ALAC was not usable in 
a CAF container...


I assumed that ALAC compression is for Apple-only devices, but it works 
on other platforms as well, and a quick test shows that ALAC can be a 
bit more efficient than WavPack (for file size, no idea about CPU usage).


So using the Ambix format in a CAF container with ALAC compression is a 
good choice.


Marc

Le 2021-05-23 à 06 h 37, Fons Adriaensen a écrit :

On Sat, May 22, 2021 at 06:15:48PM -0400, Marc Lavallée wrote:


In the document, "Universal Ambisonic" is described to work with WavPack.

"Universal Ambisonic" is as dead as can be, and that's probable the
best that could happen to it. It was precisely a desire to get rid
of ill-conceived 'standards' like this that motivated the design of
the Ambix format. Which is also what everybody uses today.

As an audio file format Wavpack is rather primitive. It could be
useful as a format for content delivery to the end user, but for
production it is pretty useless.

AFAIK, you can convert .wav, .caf and others to Wavpack and back
again, but only the audio data is preserved. Both WAVEX and CAF
support a lot of other data as well.

Wavpack was considered by the Ambix designers as a way to cater
for unused channels (like for horizontal-only AMB). These would
simply be set to all zeros and compressed to only a few bytes.

But the matrix based method was chosen in the end as a better
alternative that also offered other functionality.

The reason why CAF was chosen was that it was (and still is) the
cleanest and most versatile format available.

CAF has several advantages:

* 64-bit filesize, no problem with long multichannel files exceeding
   the size limit.

* Support of 'user' extensions. CAF is a 'chunked format' (like WAVEX),
   and it also supports UUID [1] chunks, extensions that are identified
   using a 128-bit unique identifier. These can be used without needing
   approval or registration by Apple. Any software that doesn't know
   how to interpret a particular UUID chunk should just ignore it.
   Thus users can extend the format in a way that is future proof and
   that will never be in conflict with other extensions. This is how
   the Ambix 'extended format' is implemented and why it requires CAF.

* No history of unofficial variations and extensions with all the
   resulting fragility.

Now compare that to what happened with the WAV format. The original
WAV specs where quite ambiguous in some respects, and also lacked
functionality. So various unofficial and mutually incompatible
vendor extensions started to appear, and pretty soon a .wav file
created by software X could not be used by software Y.
More than 20 years ago Microsoft decided the clean up the resulting
mess and created the WAVEX format. Since then, every .wav file that
has more than 2 channels or uses more then 16 bit resolution has to
use the WAVEX format. But there are still a lot of defective WAV
files around, and WAVEX has no way to add UUID chunks as in the
CAF format (they could be added easily, but that has not happened).


Ciao,


[1] 


___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: [Sursound] WavPack (was: Re: Ambix files)