Skip to content. Skip to navigation
About- Blog- for contributors- Forum- Wiki- Podcasts- Google Maps- Members- Contact us
hello

The next generation
surround sound experience,
by the enthusiasts, for the
home theatre.
Personal tools
> Home → Members → etienne → Successor format for B-Format
Document Actions

Successor format for B-Format

by etienne deleflie — last modified 2005-11-20 19:16

File Extension

Remains *.amb


Channel Format

Remains identical as described on this page


File Format

Compressed or not?

Not being able to do 64 Bits is determined not to be a problem.

preferred

proposed
  •       ?
    
  1. WAVE-EX format  (here) limited to 4 Gig
  2. FLAC (explained here). Is there a size limit for FLAC(?)
  3. W64 (sonic foundary, well supported by open source libraries (libsnd etc.),
    oes multi-channel files, does 64 bit (or not), file size not limited to 4gig...
    but does not seem to be well supported by commercial apps)
  4. CAF (http://developer.apple.com/documentation/MusicAudio/CoreAudio-date.html)

Description of shelf filters in the header (once agreed upon)

Full (unabiguous) support up to N order, including horiz/height mixtures. 

FLAC (or whatever) compression of N channels 

XML or other representation of encoding/decoding coefficients > (once agreed upon!) 

UHJ support up to 4 channels 

Probably 64bit chunk sizes for beyond the 4GB barrier 

3 DB down

Posted by msr at 2005-11-08 20:20

No matter what, there will be problems with B format and 3 db down. W levels are really a matter of taste and desired size of the image, so a +/-6db knob on the front of the player should take care of all eventualities. My recomendation, use the full available bit count and encode it 0 db down.

Wave-EX

Posted by msr at 2005-11-08 20:25

The format is not that important as long as the file has some internal mechanism to distinguish the layout of the contents. Wave-Ex was choosen for this reason. Other formats may be just as capiable. 64 bit audio is not a requirement IMHO. Mechanically our best recordings are 18 to 20 bits of real resolution at present. (before noise floor)

Lossy compression

Posted by relen at 2005-11-09 09:06

Before considering the use of lossy compression on B-Format signals - or on sets of reversible speaker feed signals - the impact, if any, on the decoding of B-Format or pseudo-B-Format signals resulting from such compression must be evaluated.

B-Format & G-Format

Posted by relen at 2005-11-09 09:10

The above file format defines a structure for encoding and distributing B-Format signals. Do we need an addendum to handle G-Format (ie Ambisonic recordings decoded to loudspeaker feeds in a standard array) including the ability to recover B-Format (or something like it) for subsequent decoding?

Apple CAF

Posted by mleese at 2005-11-11 15:59

Number 4 in the list of proposed File Formats is CAF. Details of the Apple Core Audio Format Specification 1.0 is available at: http://developer.apple.com/documentation/MusicAudio/CoreAudio-date.html

Regards, Martin

The Full Monty

Posted by mleese at 2005-11-18 21:28

Richard Dobson summarised it well ... > Whereas for the full Monty, people have been discussing: > > Description of shelf filters in the header (once agreed upon) > Full (unabiguous) support up to N order, including horiz/height mixtures. > FLAC (or whatever) compression of N channels > XML or other representation of encoding/decoding coefficients > (once agreed upon!) > UHJ support up to 4 channels > Probably 64bit chunk sizes for beyond the 4GB barrier > G Format > All playable on "standard" Media Players! ... > Did I miss anything?

To which I added: A binary flag to indicate whether the W channel has been -3 dB attenuated or not. That way, it becomes optional.

Regards, Martin