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

[Marc Lavallée]

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)

[Marc Lavallée]

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: 

___
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)

[Stefan Schreiber]

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,



 --

 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.

-- 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)

[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] WavPack (was: Re: Ambix files)

[Fons Adriaensen]

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)

[Marc Lavallée]

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)

[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.

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

[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] 
>
> --
> 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: 

___
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)

[Stefan Schreiber]

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:  



 ___

 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: 

___
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)

[Fons Adriaensen]

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] 

-- 
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)

[Bo-Erik Sandholm]

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: 

___
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] WavPack (was: Re: Ambix files)

[Marc Lavallée]

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
> 
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.