It obviously would be nice to have such a mode available, for e.g. DVD audio compression. Apparently, the list doesn''t tell me too much about it. My questions are: 1. What is the current status of the 5.1 channel coupling in Vorbis? 2. If I''ll be interested in participation in its development, what is the recommended reading? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20070118/c63df1a9/attachment.htm
On 1/18/07, Qduaty <qduaty@gmail.com> wrote:> 1. What is the current status of the 5.1 channel coupling in Vorbis?It''s a bounty open by Xiph for a good long while now. Status isn''t good. Although, Vorbis can do multi-channel, quality as far as I''ve heard is pretty bad.> 2. If I''ll be interested in participation in its development, what is the > recommended reading?You could look in the MIT library for audio engineers, I suppose. The more important thing you''ll need is probably proper equipment for testing. At least, according to what Aoyumi-san (developer of aoTuV) told me. Best wishes, Ivo Emanuel Gon?alves
2007/1/19, Ivo Emanuel Gon?alves <justivo@gmail.com>:> > You could look in the MIT library for audio engineers, I suppose. The > more important thing you''ll need is probably proper equipment for > testing.But what about the implementation in Vorbis? As I understand, Vorbis supports 2-channel coupling. This implies all multichannel surround models must have 2^n channels. There may be two ways to deal with it: 1. Implement n-dimensional channel coupling 2. Treat 5.1 dolby digital content as 4-channel surround + 2 independent channels (dialogs + LFE) In the second case, we can use two models of quadrophony: a) independent coupling for front and back channels, then coupling front with back L -- R | L'' -- R'' b) generate two perpendicular pairs of channels, which gives us possibility of mixing down the dialog channel into the Front. Both pairs could be coupled independently: Front Left + Right Back What you people think about it? ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20070120/69ebd4a9/attachment.html
I expected for someone to get in touch with you, and help you get in the right track. Most unfortunately, no one did. I''m not in the know of the technical details on how Vorbis deals with multi-channel, so all I can suggest if you are still interested, is to check the vorbis source code, and maybe oggenc''s source code as well. Someone on the Xiph wiki added some interesting links for Ambisonics stuff. That may be of use to you as well. I''ll pretty much copy&paste it: "Resources on Ambisonics * There is now a set of articles on Wikipedia on Ambisonics [ http://en.wikipedia.org/wiki/Ambisonic ] * Of particular relevance is the ".amb" specification [ http://www.ambisonicbootlegs.net/Members/mleese/file-format-for-b-format/ ] for downloadable B-Format files. There are currently about 75 pieces available in this format for free download. Most of these are full-sphere soundfields. * My website [ http://members.tripod.com/martin_leese/Ambisonic/ ] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites)." Hope this helps, Ivo Emanuel Gon?alves On 1/20/07, Qduaty <qduaty@gmail.com> wrote:> But what about the implementation in Vorbis? As I understand, Vorbis > supports 2-channel coupling. This implies all multichannel surround models > must have 2^n channels. There may be two ways to deal with it: > > 1. Implement n-dimensional channel coupling > 2. Treat 5.1 dolby digital content as 4-channel surround + 2 independent > channels (dialogs + LFE) > > In the second case, we can use two models of quadrophony: > a) independent coupling for front and back channels, then coupling front > with back > L -- R > | > L'' -- R'' > > b) generate two perpendicular pairs of channels, which gives us possibility > of mixing down the dialog channel into the Front. Both pairs could be > coupled independently: > Front > Left + Right > Back > > What you people think about it? ;)
2007/1/25, Ivo Emanuel Gon?alves <justivo@gmail.com>:> I expected for someone to get in touch with you, and help you get in > the right track. Most unfortunately, no one did.Maybe they want me to google in their ancient threads? This will happen soon. Thanks for> "Resources on AmbisonicsIt seems to be exactly what I thought about. Anyway, I didn''t expected silence here. It looks like the subject were exhausted several years ago; no one is interested in to keep it alive now. So, do we still need a Vorbis Surround? Now, while we have thanks God 2007, people on forums keep waiting for it to be ready. Regardless of coding, I can help with having an optimal room (near 0.8x1x1.25, ~120 m3), ready for listening experiments; I know some people who would help me with tests, both with their ears and equipment. After first alpha release, it could be possible to talk with cinemas, culture clubs, to perform tests in their halls. That''s my 50 cents ;)
On 1/25/07, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote:> multi-channel, so all I can suggest if you are still interested, is to > check the vorbis source code, and maybe oggenc''s source code as well.How about the ''Ogg Vorbis stereo-specific channel coupling discussion'' ( http://xiph.org/vorbis/doc/stereo.html )? Came across it just yesterday. In my understanding it suggests the approach is extensible and doesn''t necessarily require 2^n (2*n even?) channels or separate couplings? Just my other half of the... was it Euro? ;) Regards, Arek
2007/1/26, Arek Korbik <arkadini@gmail.com>:> How about the ''Ogg Vorbis stereo-specific channel coupling discussion'' > ( http://xiph.org/vorbis/doc/stereo.html )? Came across it just yesterday. > In my understanding it suggests the approach is extensible and doesn''t > necessarily require 2^n (2*n even?) channels or separate couplings?Maybe I don''t understand it well, but I didn''t ever see any solution for surround in that discussion, and I have read it several times. Just two channel coupling and a promise that the model is extensible. After googling for "site:lists.xiph.org surround ambisonic 5.1", I started to encode some movie soundtracks as 3-channel, B-Format Ambisonics, with such assumptions: 1. Movies have just several sources of sound (namely, speakers) so even if B-format is encoded with plain FMH equations, the only artifact noticeable will be that dialogs are in front of the screen (equations assume all speakers have the same distance from the microphone). This is not an issue - the goal is to check whether Vorbis can encode it all at 128 kb/s, with reasonable quality. 2. As there are no known directx filters for Ambisonic-encoded movie sound tracks, the decoding has to be done the same way as encoding, i.e. without latencies, nor filtering. 3. My encoding setup consists of 5 channels; LFE is simply mixed down into W. Four channels are put in a rectangle, where X axis (in ambisonic terms) is a bit longer than Y. This is to cancel the mentioned dialogs-related artifact. Center channel stays in its place between L and R. 4. As there is also no known audio standard that took 3 channels of sound (except Ambisonics) it''s even safe to assume these encodings will be decodable in future, by assuming they are Ambisonic WXY B-Format. MPlayer + oggenc + OGMuxer (or mkvtoolnix, or ffmpeg2theora) can handle it all. Actually, I just started listening...
qduaty <qduaty@gmail.com> wrote: ...> After googling for "site:lists.xiph.org surround ambisonic 5.1", I > started to encode some movie soundtracks as 3-channel, B-Format > Ambisonics, with such assumptions:... I have been doing some work on the Ambsionics page at http://wiki.xiph.org/Ambisonics You might want to take a look. Regards, Martin -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web: http://members.tripod.com/martin_leese/
Apart from the information that''s already available (Vorbis specification, the stereo.html thingy that explains among other things what square polar mappint is about, discussions) some of the following ideas/views/suggestions might be helpful for implementing "multichannel coupling": [ 2 channel coupling revisited ] - square polar mapping (with IMHO limited benefit) - residue vectors can be interleaved - interleaved residue vectors + VQ allows exploitating inter-channel redundancies [ How does Dolby Digital work w.r.t. multichannel coding? ] - A channel (L,R,C,SR,...) can either be a "full bandwidth" (FB) channel which means it''s coded independently from the others OR a channel that takes part in the "coupling" process. - The number of non-FB channels is either 0 or >=2. - If non-FB channels exist, their lower spectrum part is coded normally (independently). All non-FB channels borrow their higher spectrum part from "the coupling channel" whose gain is determined by the channel''s "coupling coordinate". => "intensity multichannel coding" [ Possible multichannel extensions for Vorbis ] (1) Do "pairwise coupling" like it''s done with normal stereo material. Either in a fixed way or adaptivly (requires more modes to be declared in the codec setup packet and switching between them) EXAMPLE for >=4 channels: mode1: coupling (L+R) and (SL+SR) "independently" mode2: coupling (L+SL) and (R+SR) "independently" An encoder may adaptivly switch between both modes or use just a fixed one like mode1 for the whole stream. PROS: should be fairly simple to implement. CONS: only pairwise coupling. (2) Do "n-way-coupling" (n>2) where more than two channels are used via cascaded square polar mapping. Let''s see how well this works: // pseudo code example for 5-channel "cascaded" SQPM: void sqpm(resVec* ch1, resVec* ch2) { // square polar mapping // ch1 becomes "magnitude" // ch2 becomes "angle" } : resVec* ch1 = L; resVec* ch2 = R; resVec* ch3 = C; resVec* ch4 = SL; resVec* ch5 = SR; sqpm(ch1,ch2); sqpm(ch4,ch5); sqpm(ch1,ch4); sqpm(ch1,ch3); This way Dolby-like "intensity multichannel coding" can be done via setting residue vector ch1 *appropriately* and the others to ZERO. So far so good. Problem is: You only want to do this intensity coding for the higher spectrum part. Since square polar mapping can only be applied on the whole audio band you have to use SQPM and code the lower spectrum parts of ch2...ch5 for a kind of "lossless coupling". Next problem is: The lower spectrum parts are still correlated since square polar mapping isn''t good at decorrelating things. That''s why in 2-channel streams they are usually interleaved and VQed to not waste any bits. This is where it''s getting nasty because IN THIS CASE you have to interleave many channels. You *don''t* want to design high dimensional and large VQ codebooks for those interleaved residue vectors! Conclusions: Stick with pairwise channel coupling for multichannel signals. I believe this is what MPEG2/4 AAC does anyways (me guessing!) Comments? Cheers! Sebastian
Yes, we absolutely, really, really need 5.1 (etc.) modes for the vorbis encoder! This is really important for pushing free formats, especially in the video realm. There are a number of low hanging fruit, as have been suggested, including treating things as stereo pairs, doing a separate mode that takes into account the low pass for the LFE channel(s), and extending the square-polar mapping to >2 channels. There''s probably at least a factor of two in bitrate to be gotten here. The step after that is to do a special tuned mode set for 5.1, taking into account the mixing strategies used in practice. This is much harder, requiring a golden ear and some working knowlege from the industry. Monty has also cited the lack of (not lossily compressed) 5.1 sources to test with as an obstacle here. The second step is what''s needed to get quality/bitrate up to the same standards we offer for stereo, but that shouldn''t stop anyone from working on the first step. For that all you need is a listening setup and a willingness to experiment with the code. I expect reasonable initial progress can be made with transcoded AC3 tracks from DVD-Video discs. As far as lossless masters, we have the CC Elephant''s Dream sound track, and a (not distributable) 5.0 classical music SACD master so far. If you have a master you''re willing to let us tune against, please let me know. FWIW, -r
On Thu, Jan 25, 2007 at 02:31:13PM +0000, Ivo Emanuel Gon?alves wrote:> Someone on the Xiph wiki added some interesting links for Ambisonics > stuff. That may be of use to you as well.So, ambisonics are just expanding the sound field in spherical harmonics. This is the proper mathematical generalization of mono and stereo, whereas the dolby N.M schemes assume a particular speaker placement. With the extra layer of abstraction (and a lot of speakers) one can achieve more accurate recording and reproduction of sound fields. However, most of the ambisonic literature is based on the the original quadrophonic implementations (where were also patented) and this isn''t enough channels to accurately represent the planar source arrangment most content is mixed for. Furthermore, since the vorbis spec has no room for a channel mapping table, there''s no efficient way to specify a subset of ambisonic modes you want to encode for a better match. So, while it''s an interesting thing to work on, it''s a different and longer-term project than implementing good support for the 5.1 surround mixes most people currently want to encode. The tradeoff becomes more attractive when you have 8-12 surround channels, not just 6, and care about 3D soundscapes (like in games, art installations, and so on) than in film. -r
2007/2/1, Ivo Emanuel Gon?alves <justivo@gmail.com>:> E-mail me whatever files you need hosted, and I'll put them online. I > have some spare bandwidth for the next months.As we have talk a moment ago, there are legal issues that prevent us from making movie soundtracks public. The solution is anyone can create such samples themselves. My procedure is: Assume we have a ripped dvd file called "movie.vob", with a 5.1 audio track. Download and install mplayer. Type: mencoder movie.vob -o sound.avi -ovc frameno -oac pcm -channels 6 -af pan=3:.7071:.7809:.6247:.7071:.7809:-.6247:.7071:-.7809:.6247:.7071:-.7809:-.6247:.7071:1:0:.7071:0:0,volume The pan filter works as follows: first number is a number of output channels, then they are exactly so many weights separated by colons for an input channel, then next input channel, and so on. Channel order is: L,R,LS,RS,C,LFE. All coefficients are angle sinuses and cosinuses. The actual values are not so important but they have to correlate (ambisonic encoding equations are quite easy to understand: look at http://www.muse.demon.co.uk/ref/speakers.html). Actually my initial setup was somewhat different (0.6202 instead of 0.7809), which gave a longer X-axis. The command creates an empty video with a 3-channel pcm sound. The file is about 1 GB per hour. Oggenc can't handle avi, so we have to issue mplayer sound.avi -dumpaudio This throws out a stream.dump file (raw audio). Then oggenc -q0 -R 48000 -C 3 stream.dump works as expected. After encoding, we can test the results: mplayer movie.vob -audiofile stream.ogg -channels 6 -af pan=4:0.3536:0.3536:0.3536:0.3536:0.3536:0.3536:0:0:0.3536:-0.3536:.5:-.5,volume The pan filter in above command is intended for two speakers + headphones, for convenience. It is diametric ambisonic decoding, so there may be some phase-related issues. Plug your headphone jack into the rear sound output, test with mono to be sure loudness is equal in front and back channels. A decoding setup for ITU 5.1 is discussed on http://pcfarina.eng.unipr.it/Public/B-format/5_1_conversion/5_1_decoders.htm.
>A decoding setup for ITU 5.1 is discussed on>http://pcfarina.eng.unipr.it/Public/B-format/5_1_conversion/5_1_decoders.htm.A good Ambi to 5.1 decode is at http://www.e-wig.co.uk/sursound/gformat_ac3.jpg Bruce Wiggins has good Decoders using this and for other layouts at http://sparg.derby.ac.uk/SPARG/Staff_BW.asp More useful than the Vienna decodes But you get much better results if you decode to a square or rectangle 4.0 layout. "Ambisonic Surround Decoder" from ambisonicbootlegs.net\Members\ricardo discusses this and has more references. The definitive document on horizontal Classic Ambisonic Decoders is "SHELF FILTERS for Ambisonic Decoders" from the above site.>but it's a much easier problem for a lossless codec. right now, except for stereo, channels are always coded independently, mainly because I haven't done much research into patent-free multichannel decorrelation schemes.Ambisonic B-format has a lot in common between channels. So there might be an argument for coupling each of the XYZ velocity signals to the W omni signals. But there is a caveat. Does Vorbis coupling preserve "phase" relations? Any references explaining this in simple detail? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 2138 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20070203/16330053/attachment.bin -------------- next part -------------- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 1/02/07 14:28
Hi! Saturday 03 February 2007 01:30-kor Sebastian Gesemann ezeket a bolcs gondolatokat fogalmazta meg:> You're not the only one. I also think square polar mapping (SQPM) is a > waste of time. It should be possible to losslessly transcode *current* > Vorbis streams so they don't use SQPM. Of course this would involve > "rearranging the codebooks".Exactly what I thought! I was thinking of implementing this, but so far lazyness/not seeing too much point in the effort prevented me from doing so :).> > Monty addresses this point in http://xiph.org/vorbis/doc/stereo.html , >[...] > Though, I fail to grasp why SQPM is beneficial when it comes to > multi-stage vector quantization.Thanks for the quote - although I have read the document, I might have not paid enough attention, because this part didn't catch my attention! Monty might be on to something there, but neither I think that SQPM would give a measurably large boost to the multi-stage vq efficiency - especially for lattice vq. But maybe it does.> > Cheers! > Sebastianbye Denes -- --- What kills me, doesn't make me stronger.
On 2/13/07, Sebastian Olter <qduaty@gmail.com> wrote:> PATCH: > > Two lines have to be changed in audio.c to prevent oggenc (1.0.2) from > rejecting wave-ex/amb files: > > > 389c389 > < if(len!=16 && len!=18) > --- > > if(len!=16 && len!=18 && len != 40) /* 40 is wave-ex */ > 415c415 > < if(format.format == 1) > --- > > if(format.format == 1 || format.format == -2) /* -2 is wave-ex (at least on x86) */ >Was the above patch for oggenc already applied, or at the very least tested? And related with this subject: have you people been checking http://wiki.xiph.org/index.php/Ambisonics for updates? That page is shaping pretty well. Every question or doubt on Ambisonics should be clear by now; now we just need working code to make Ambisonics on Vorbis a reality, starting with oggenc. -Ivo
2007/2/21, Ivo Emanuel Gon?alves <justivo@gmail.com>:> Was the above patch for oggenc already applied, or at the very least tested?There are Windows binaries of the modified oggenc for both CPU architectures and I can provide them if needed.> now we just need working code to make Ambisonics on > Vorbis a reality, starting with oggenc.Yesterday I have finished writing the ambisonic pan filter for oggenc. Before I send it to trac, I want to test these new functions for bugs. If you think it is valuable to submit a not-well-tested patch right now, I could post it here.
On 2/21/07, Sebastian Olter <qduaty@gmail.com> wrote:> 2007/2/21, Ivo Emanuel Gon?alves <justivo@gmail.com>: > > Was the above patch for oggenc already applied, or at the very least tested? > > There are Windows binaries of the modified oggenc for both CPU > architectures and I can provide them if needed.That question was actually for the oggenc maintainer, but thanks for the feedback.> Yesterday I have finished writing the ambisonic pan filter for oggenc. > Before I send it to trac, I want to test these new functions for bugs. > If you think it is valuable to submit a not-well-tested patch right > now, I could post it here.Well, you end up posting it regardless. Suggestion: next time you need/want to post code on a mailing list, it may be better to attach it, so to avoid a message body so large. Just a suggestion. If you submit the patch to trac after doing more tests, you will be a hero. There will be tales and songs written about your feats. And happy days will be upon us. -Ivo