Hello, I've been postponing some of my encoding for when joint stereo gets implemented. The reason I've been doing this, is that I am under the impression this is the largest step in the quality/bitrate ratio that's left. Now I'm wondering if I am correct in thinking this. lame's documentation seems to imply it doesn't make much of a difference at higher than 128kbps (I quote: "To disable joint stereo encoding (slightly faster, but less quality at bitrates <= 128 kbps)"), but this could just be because one anyway doesn't hear much of a difference between 128 and 160 kbps? Secondly, this feature doesn't _appear_ to be too high on the priority list. (Or is it just technically a lot more difficult than the other features?) I know this is supposed to be in Vorbis 1.0, which should be released before the end of the year. Is it likely that we will have to wait until nearly 1.0 for jstereo, or are there plans to implement it within, say, the next two beta's? (And are there any dates attached to this? I suppose not.) Thanks, Hugo van der Merwe --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hugo van der Merwe <hugovdm@mail.com> wrote:> I've been postponing some of my encoding for when joint stereo gets > implemented. The reason I've been doing this, is that I am under the > impression this is the largest step in the quality/bitrate ratio that's > left.I think that's true. The saving that is achieved by using joint stereo varies - if there is big stereo separation & difference between audio channels then the gain is small/none, but in practice this rarely happens so usually you can save ~30-40kbps by using joint-stereo, and sometimes even more.> Now I'm wondering if I am correct in thinking this. lame's > documentation seems to imply it doesn't make much of a difference at > higher than 128kbps (I quote: "To disable joint stereo encoding > (slightly faster, but less quality at bitrates <= 128 kbps)"), but this > could just be because one anyway doesn't hear much of a difference > between 128 and 160 kbps?It does make a difference - and LAME is a good example :-) From my experience, using LAME at 192kbps you will get less artifacts when you use joint-stereo instead of simple stereo. Also most test files sound better at 256kbps JS then 256kbps S. Bottom line: if joint-stereo is properly implemented (and LAME has pretty good joint-stereo), then I don't see the point in using simple stereo because you will only get bigger files and they won't sound better... of course there is still probability that joint-stereo might slip up somewhere but as I said, if the implementation of joint-stereo is good then there is no worry. Only at high bitrates (depends on the codec, but generally speaking ~256kbps and higher) you should/could use simple stereo, because at such high bitrates there are enough bits so there is no real need for savings (and you also avoid that small slip up probability of joint-stereo). Greetings, Aleksandar --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I've been postponing some of my encoding for when joint stereo gets > implemented. The reason I've been doing this, is that I am under the > impression this is the largest step in the quality/bitrate ratio that's > left. Now I'm wondering if I am correct in thinking this. lame's > documentation seems to imply it doesn't make much of a difference at > higher than 128kbps (I quote: "To disable joint stereo encoding > (slightly faster, but less quality at bitrates <= 128 kbps)"), but this > could just be because one anyway doesn't hear much of a difference > between 128 and 160 kbps?The problem with joint stereo is that the perceptual qualities of the two encodings can sound very different, and if the selection algorithm makes a mistake... It may also be the case that you also may not notice a quality difference between the two modes (L/R or mid-side), but you would notice the transition from one mode to the other. Because the selection algorithm is not perfect, at higher bitrates, LAME turns joint stereo off by default.> Secondly, this feature doesn't _appear_ to be too high on the priority > list. (Or is it just technically a lot more difficult than the other > features?) I know this is supposed to be in Vorbis 1.0, which should be > released before the end of the year. Is it likely that we will have to > wait until nearly 1.0 for jstereo, or are there plans to implement it > within, say, the next two beta's? (And are there any dates attached to > this? I suppose not.)b3 will not have it (yes, it's somewhat more difficult than other features). b4 *will* have it. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Monty <xiphmont@xiph.org> wrote:> The problem with joint stereo is that the perceptual qualities of the > two encodings can sound very different, and if the selection algorithm > makes a mistake... > It may also be the case that you also may not notice a quality > difference between the two modes (L/R or mid-side), but you would > notice the transition from one mode to the other. > > Because the selection algorithm is not perfect, at higher bitrates, > LAME turns joint stereo off by default.As far as I am into the technical side of joint-stereo, joint-stereo implemented in Vorbis will be different then MP3. MP3 j-stereo algorithm determines whether M/S or L/R will be used on a frame-by-frame basis, while Vorbis does that but not for the whole frame - it is focused on frequency regions... ? That is why it's not an easy job...> b3 will not have it (yes, it's somewhat more difficult than other > features). b4 *will* have it.What will be the main differences between b2 and b3? B3 coming out soon? Greetings, Aleksandar --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Monty <xiphmont@xiph.org> wrote:> > What will be the main differences between b2 and b3? > > B3 coming out soon? > Bugfixes, API improvements/additions. b3 is to be Very Soon; the 31st > was the plan, that's looking a little tight. You know about me and > deadlines.Just wondering, how are you going to squeeze in another beta (after b3), when the date for version 1.0 is set for the end of this year? :-)> (However, my wife's off on business for two weeks, so I have > relatively unlimited hacking time :-)This partially answers my previous question... ;-) Greetings, Aleksandar <HR NOSHADE> <UL> <LI>application/octet-stream attachment: foto.jpg </UL> -------------- next part -------------- A non-text attachment was scrubbed... Name: foto.jpg Type: application/octet-stream Size: 2365 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis/attachments/20001030/d5088b06/foto-0001.obj