is it a larger bitrate, same quality? or is it both "lower quality" (as the joint stereo advocates like to point out) AND larger birate?

(yes, i still like to "fake" surround sound with the KB 5.1 audio out plugin -- after a couple years of a break from it :)

It's a good question I've wondered about.

Clearly if joint stereo uses 320kbps for a frame and encodes it as M/S, then forcing discrete stereo can/will result in lower quality, possibly audibly so, since a higher bitrate is required to maintain the same quality, but the higher bitrate is not available.

As for the rest of the time, who knows? I was looking at the issue of mono encoding, and found that lame's psy model didn't behave as expected, so it's always possible that you might unearth hidden "features" by forcing discrete stereo, since all testing and tuning for this mode/preset has been carried out using joint stereo.

Cheers,
David.

I just tried this with two test files using LAME 3.97.


File 1 (this has quite average channel separation, the stereo effect is clearly audible):

-V 2 --vbr-new resulted a 209 kbps mp3 file with 63.9% ss and 36.1 % ms frames (according to EncSpot Pro).
-V 2 --vbr-new -m s resulted a 212 kbps mp3 file.

File 2 (this is near mono):

-V 2 --vbr-new resulted a 179 kbps mp3 file with 8.3% ss and 91.7 % ms frames (according to EncSpot Pro).
-V 2 --vbr-new -m s resulted a 190 kbps mp3 file.


I may be wrong, but I would like think to that fully preserving the same quality would need a bigger bitrate increase. I didn't try to ABX the difference.

Edit: fixed a typo

With a bit identical dual mono file, I get...

114.8kbps for joint stereo (100% M/S)
197.7kbps for discrete stereo (100% L/R)
100.4kbps for mono (100% mono!).

To get an idea of the coding noise (which I don't claim to hear, never mind ABX!) I inverse mix pasted the original over each version and get an average / maximum / total RMS error of...

joint stereo -40.91 dB -39.27 dB
discrete stereo -39.18 dB -27.58 dB -37.46 dB
mono -39.19 dB -27.58 dB -37.48 dB

So nearly 2dB lower coding noise for joint stereo than discrete stereo.

(And, interestingly, nearly the same noise for forced discrete stereo as for mono, implying that discrete stereo really does treat the audio as two independent mono signals. I inverse mix pasted the mono and discrete stereo version, and found them to be bit identical apart from maybe ~100 52ms frames out of 8340 frames. In the -m m version, 52 frames were over 160kbps, so that accounts for much of the difference, since this would imply more than 320kbps would be needed to maintain these frames in discrete stereo).


In short, for -V 2 --vbr-new in lame 3.97, discrete stereo encoding of a dual mono file is apparently bit-identical to mono encoding of the same file, except where the maximum bitrate limit is reached, and maybe in some other rare unknown circumstance (unless I miscounted - more likely!).

Joint stereo is objectively more accurate.

No ABX or listening test results supplied or offered, no relevance to audible problems claimed (though, to me, it suggests discrete stereo or mono is either more efficient (if you can't hear the difference), or audibly worse (if you can), than joint stereo).

Cheers,
David.

I use KB5.1 myself (matrix with L/R duplicated to the rears, vorbis q0 ). If you are actually using the 'rear' channels in that plugins settings.. then I would avoid joint stereo if I were you. Plain stereo will give you better seperation in the rear channels, and you can avoid the headache of ringing/flanging/distortion nastyness

When I tested this (by the way 'centercut' can be used for the test as well) I only used low bitrate mp3 (~112kbps). The only thing I was concerned about in my test was the channel separation, which was much better with plain stereo.

Considing how you will be using these files, I would go with plain stereo regardless of the 'potential quality loss if you "need" more than 320kbps for a frame'.

112kbps mp3 with forced discrete stereo. I think I'm going to be sick...!

(I assume it was just for testing).

Cheers,
David.

Without M/S stereo, a track with vocal in the center can't be well encoded. Here (TomsDiner) is a example. I think you can abx these two of mp3.

I'm not sure V2 has same scenario. -m s can fix rare stereo issue but mostly decrease efficiency.

Contrary to the current trends these days (which I've found is followed more religiously on popular audio forums such as this one, compared to the mp3s I actually find for download...maybe it's the type of music I'm interested in) at high bitrates I'm still a big supporter of forced plain stereo, or even dual-channel, as opposed to joint-stereo (forced or switching).

A lot of my encoding preferences have to do with encoding philosophy, rather than a direct demand for the highest quality possible. At 320 kbits/s, practically everything will be encoded transparently whether in Stereo or Joint Stereo, and the few samples that might have noticeable artifacts could still have artifacts even with Joint Stereo (in other words, a true 'problem sample' at 320 kbits/s is unlikely to be fixed by increasing bitrate further via Joint Stereo, it's more likely to be a 'problem sample' that exists regardless of bitrate). Furthermore, the most difficult-to-encode frames are highly likely to have a high stereo separation and LAME would encode those frames in L/R mode anyway, so Stereo vs Joint Stereo would be the exact same quality for that frame. Finally, from a philosophical standpoint, at high bitrate sometimes 'worse quality' is actually better. At 320 kbits/s one might aim for 'consistency' of audio quality rather than the 'best possible audio quality at all times.' For example, you might have a song where a complex sound is coming out of the center, then moves around to the left and/or right sides. If you encoded with Joint Stereo, it is possible that the complex sound would be encoded transparently when in the center, but sound slightly artifacted when it moves to the side(s). If you encoded with Stereo, that complex sound would always be slightly artifacted but at least it would always be artifacted the same...this could be preferrable and less bothersome, especially if you didn't have the source WAV and don't know that your sound is slightly artifacted to begin with.

I disagree, especially at higher bitrates. If you use LAME, many of your audio frames will be encoded in L/R mode anyway, so your 'vocals in the center' will be just as bad (during the most difficult-to-encode parts that have other instruments with stereo separation, in addition to your center vocals) during those times whether you encode in Stereo or Joint Stereo. In the best-case times though, the vocals in the center will be better encoded, but that would mostly only be a concern for low to medium-bitrate encodings (128 and 160 kbps, possibly 192 and 224 kbps as well).

I've wondered about this also, but I have several ideas on this issue that make me think that Stereo VBRs should not be lower quality than Joint Stereo VBRs, just bigger.

1) On the LAME Joint-Stereo VBR histograms, I noticed that the 320 kbps frames are in general mostly L/R frames anyway, very few M/S frames...compared to the lower bitrate frames. And for songs with extreme stereo separation at all times, practically the whole song, or exactly the whole song, can be L/R frames for the 320 kbps frames.

2) For the rare 320 kbps M/S frames we see, we don't know that LAME really thinks it needed the full 320 kbps. Maybe it thinks it only needed 270 kbps, but since there is no such thing as a 270 kbps frame it chose 320 kbps in M/S mode. And that same '270 kbps frame' in M/S mode might be encoded just as good in 320 kbps in L/R mode.

3) There are also potential bit reservoir issues, as LAME's VBR modes supposedly don't make very intelligent use of the bit reservoir. But supposedly it is still in use. The big reservoir could easily 'rescue' the very very rare potential 320 kbps M/S frame that you forced into L/R by encoding in Stereo.

To add to this, there are the 'philosophical' issues I discussed in my previous post, although admittedly that 'philosophy' is less consistent with the philosophy of VBR encodings (though it is still reasonably compatible IMO) and is more consistent with the philosophy of CBR encodings. But anyways, bottom line is that in my opinion Stereo VBRs are just bigger than Joint-Stereo VBRs, but not of any worse quality. That being said, when I personally encode VBRs (even high quality -V 0 ones) I generally use Joint-Stereo since I think the point of VBR is to save space and Joint-Stereo does save space. When I encode 320 kbps CBRs I generally use Stereo, due to my philosophical reasons I mentioned before. Also, in general I encode almost everything in CBR, not VBR, because I think VBRs aren't really worth it most of the time. But I encode certain things in VBR such as quasi-mono signals, or tracks (especially non-music ones) with large periods of silence inside, etc.

Anyway those are just my personal thoughts and reasonings, I don't have strong feelings on this matter (both Joint-Stereo and Stereo, VBR or CBR, can be great as long as the bitrate is high enough and a good encoder without broken switches is used -- although what I think is broken is not always in agreement with the general audio community) and don't mind if people disagree with me.

None of those explain why quality should be the same. Only why it might not be substantially worse.



Theres no delicate way to put this, so I'll be blunt:

Your philosophical approach to audio compression is stupid, and no one cares about it. Maybe you could stop posting about it. It makes wading through your posts annoying.

My philosophy is to reject all philosophical musings on a subject backed up with objective scientific and mathematical theories.

Why don't you just, you know, move on to a forum better suited to your philosophy since you apparently regard Hydrogenaudio as 'religious', when I have seen this forum take flak for being too scientific.

As an aside, I am disappointed whenever I see a non-joint-stereo mp3 file encoded with Fraunhofer.

My dear Porcupine,
448 words, 2063 characters in one post, but where is the sense?

You thought that was bad...
http://www.hydrogenaudio.org/forums/index....=54109&st=0

Honestly though, he does like to pontificate verbosely with little (if any) supporting evidence.

I was under the impression that statements made here at HA were to backed by objective evidence, not unsupported philosophical musings with no basis in empirical reality. As people in this thread have already pointed out, that reality suggests that forcing stereo frames usually leads to lower quality because:

a) Problem samples exist at 320kbps even when using M/S coding (i.e., fatboy, trumpets, etc). Forcing stereo frames starves the already insufficient bitstream of bandwidth, which can only harm quality.

b) Especially when using --nssafejoint (which is enabled by default on the higher presets), joint stereo is lossless.

c) As demonstrated earlier in the thread, forcing stereo frames also leads to higher quantization/coding noise (though it's arguable as to whether anybody could hear it).

Unless you have data to support the contrary assertion that forced stereo is better than joint stereo, please stop pontificating about it. Hypothesizing is one thing, but making statements that are directly contradicted by established fact is quite another.

damnit guys... can't you see that plonk420 is just trolling? Mods, this issue has been discussed to DEATH... let's just end it now...

Seemed like an honest enough question to me.

I think haregoo addressed it rather nicely giving us an example of where a forced stereo track was both larger and had more artifacts.

It seems to me that with most of you guys here, any opinions/thoughts/arguments that do not agree with the popular principle on this board (which is not necessarily agreed upon in other venues, as I noted before) get attacked by many (not all) hydrogenaudio members in a completely unreasonable and illogical manner. Oh well.

> As people in this thread have already pointed out, that reality suggests that forcing stereo frames usually leads to lower quality

I may not have provided any ABX logs or samples for download, but I made no claims that what I said I have tested empirically. What I said were merely philosophical arguments, that are extremely difficult or impossible to test empirically. Even though I have provided no "empirical evidence", no acceptable empirical counter-evidence has been given either. What I am discussing is not really something that lends itself to empirical testing, for some reason this board seems totally against such ideas.

I should also remark that this thread was started by someone who does not necessarily conform to this board's views either, so he should be the one to say whether or not my thoughts are welcome, not the 'hecklers' on this forum.

> Problem samples exist at 320kbps even when using M/S coding (i.e., fatboy, trumpets, etc). Forcing stereo frames starves the already insufficient bitstream of bandwidth

Many (not all) problem samples at 320 kbps are the result not of insufficient bitrate, but of more fundamental flaws in the mp3 codec and or encoder itself. Do these problem samples (fatboy, etc) play flawlessly at a higher bitrate than 320 kbps? If they do, then your argument has merit. If they have never been demonstrated to play flawlessly as a mp3 before, then you can't assume the problem is due to a lack of bits.

> Especially when using --nssafejoint (which is enabled by default on the higher presets), joint stereo is lossless.

I never said there were problems with using joint stereo in LAME. I only said that stereo mode can be just as good as joint stereo mode in certain ways, especially when you consider that LAME performs joint stereo switching between L/R and M/S mode. The majority of frames in high bitrate mp3s are encoded in L/R mode anyway, and for those frames Joint Stereo and Stereo should have the same output.

> Unless you have data to support the contrary assertion that forced stereo is better than joint stereo, please stop pontificating about it.

I never said that 'forced stereo is better than joint stereo'. And in regards to me speaking only on subjects that meet your approval, I refuse to obey you. However, if a mod asserts that your desire is also the desire of this forum, I'll probably be banned from this forum (and IMO this forum will not look very scientific to an outsider, if people are banned for arguing mathematical/philosophical points). An emphasis on empirical data is good, but this forum goes far overboard in my opinion. Empirical data with no mathematical analysis is arguably just as unscientific as mathematical analysis without empirical data.

> Hypothesizing is one thing, but making statements that are directly contradicted by established fact is quite another.

Well, you haven't provided the counter-evidence, at least not here.

> None of those explain why quality should be the same. Only why it might not be substantially worse.

Yes, that is a very good point. And I knew that from before, and I agree with you here. What I said proves nothing, it only argues that Stereo VBRs *might* not have substantially worse sound quality than Joint Stereo VBRs.

To actually choose to encode Stereo VBRs, one would really have to dislike Joint Stereo for other reasons. One such reason could be the 'philosophical' reason I mentioned earlier, but for me that's not a good enough reason so I encode my own VBRs in Joint Stereo. But to me, my 'philosophical' reason is a good enough reason to encode *320 kbits CBRs* in Stereo. That's just my own opinion.

> Your philosophical approach to audio compression is stupid, and no one cares about it. Maybe you could stop posting about it. It makes wading through your posts annoying.

I do not mind if you think my philosophical argument was stupid. I am not trying to convince everyone. I am merely trying to point out a different point of view, and everyone can decide for himself or herself whether or not my arguments have merit. To say that 'no one cares about it' is obviously wrong. A lot of people (not on this board) still prefer Stereo over Joint-Stereo for high-bitrate encodings. Most of these people probably care about my arguments.

If you find my posts annoying, you don't always have to respond to them. I appreciate the fact that you are a much more serious poster than some of the others here, but I can tell that even you don't have 100% good intentions when speaking to me. You are probably 90% genuine, 10% heckler (in my opinion). But I do greatly appreciate that your posts do add to the discussion, in general.

He gave us ONE example of a V 5 sample. For one thing, he himself said that he wasn't sure if the same thing applied to V 2, which is the topic of this thread. I am not saying his sample is completely invalid, but it doesn't prove anything definitively (just as my own philosophical arguments don't prove anything definitively, as well).

But I'm still curious, in haregoo's V 5 sample, are the distorted frames on the Forced Stereo version all 320 kbps frames? Because if they were, then that would mean that the 320 kbps L/R frames indeed introduced audible artifacts that were gone in the higher "effective" bitrate afforded by M/S mode, and Joint Stereo should be necessary to encode that sample well (at any V value). But if they weren't 320 kbps frames, then that would suggest that the the problem lies more with the way LAME behaves at V 5 (and with medium-to-high V values in general) rather than a true problem with Stereo mode. Because in theory, it could be argued that LAME should be trying to make a V 5 Joint Stereo file sound the same as a V 5 Stereo file, so the encoder could/should have simply shrunk the size of the Joint Stereo version more, until it sounded 'just as bad' as the Stereo version. I guess these would be interesting things to test if anyone cares.

I doubt it.

I can argue that joint-stereo implementation in most (if not all) Fraunhofer encoders is not good enough to replace plain stereo at relatively high bitrates (>128 kbps). Lame is the only MP3 encoder having good non-agressive M/S implementation suitable for high bitrates.

It has been pointed out in other threads that while sound sources that are mostly in the left or mostly in the right channel are best encoded with L/R frames, the same is not true for sound sources that are near the center.

This is quite logical since the separate processing of left and right channels can result in slightly different rendition of the center, differences that taken by themselves are insignificant perhaps, but since our ears process them together to create a sound image of the center, the two sources are now slightly inconsistent, making for a distortion.

If instead the frame is encoded as M/S then the center can be accurately encoded, since the center is processed by itself and is not affected by what is going on to either side. Also, I think that sound imaging of sounds near the center is more importand than sounds to the far left and right.

The advantage of M/S over L/R in this situation becomes smaller as you increase the bit rate, but I guess philosophically I just don't want to take the chance that the difference might be audible, even at 320 kbps.

At higher bitrates you can think offensive instead of defensive. Go for joint stereo and psychacoustic enhancements rather than the typical brute force approach [CBR/ABR/ LR Stereo]. That way you are maximizing quality in most cases rather minimizing it in most cases because of the rare problem sample.

At 320k if you can't hear the difference - leave it on !

Though theoretically I am also a tiny bit concerned about joint-stereo (theoretical possibility of switching problems L/R <-> M/S representation, adequate psy model for the side signal which is a difference signal) I don't care a bit about it as I don't know a single sample where this bothers me, and I am well aware of joint-stereo's part in efficient and/or increased quality encodings.

That's why I use joint-stereo with my Fraunhofer encodings though it seems that the Fraunhofer people don't have very much cnofidence in their joint-stereo implementation as they use plain stereo above CBR 192 kbps. (The alternative would have been to use 256 kbps or 320 kbps plain stereo to make up for a compensation of the inferior data representation of plain stereo, but I'm very happy with my 192 kbps joint-stereo encodings).

Pocurpine,

As a daily member of this forum for so many years, I would like you to *not* assume what this forum is and/or accepts as valid talking.

In this forum you will not find comments like "windows is shit, use linux", "macs foreva" and so on.

Those are oppinions (in this case clearly "fanboy") which might be valid, but only to a very limited situation.

Neither in this forum you'll find talks about "god exists", or any other religius content.

Those are believings, things that might, or might not exist, which empirically can't be demonstrated, and that objectivically, it has to be labeled as a believe, or has to be faced that evidence on the existance is not found, or is difficult to demonstrate.

The discussions in audio related threads many times suit those two groups:
oppinions about this codec/setting to be the best thing ever, and believings in expensive hardware that supposedly does this and that, when there's no evidence about it.


Hydrogenaudio refuses, energically, to accept anything that is both, non demonstrable, and that contradicts the knowledge that this forum has been accumulating over tests and tests, done in a controlled and repetitive environment.

So if you don't agree with the "modus operandi" of this forum, you are the one to change, not the forum.



Back on topic:

The encodes with -m s in VBR show an increased bitrate. The encoder supposedly is doing so in order to maintain the expected quality (it is, otherwise logical that a L/R representation uses more bits than a M/S one in the general case).

So the discussion obviously needs to go between what happens to L/R stereo if it has not enough bits, versus what artifacts can appear in a M/S representation which wouldn't exist in a L/R representation, *specifically* talking in the context of a (well tuned) MP3 encoder.

[Edit -> corrected some M/S L/R typos]

The problem, Porcupine, is that the start-point for potential problems isn't 320kbps, it's 160kbps. Once a JS file uses more than 160kbps for the mid channel of a joint stereo encoding, you know for a fact that it can't match that quality for near-mono content when discrete stereo is forced.

Given the number of times relatively "easy to encode" mono tracks go above 160kbps, this makes me quite uneasy. It's true that the average bitrate of such tracks is usually low - often below 128kbps. However, there are plenty of 160kbps+ frames. You wouldn't enforce a maximum bitrate of 160kbps for near mono content, would you? Yet forcing discrete stereo has the exact same effect.


The only time it's defensible, in my opinion, is when you know there will be artefacts due to joint stereo - and that's basically because you're using or faking surround sound. However, there are other threads where the interaction between JS and surround processing is discussed. You can/could get around it by forcing nsmsfix to a more conservative value. I haven't tried this with recent versions.

Cheers,
David.

Hrm, a VERY good point, which has caused me to re-think this issue further. I haven't decided yet whether I "agree" or "disagree" with this but I'll just say some of my newer thoughts on what you just said, thanks for being willing to discuss ideas like this with me.

How do you know when LAME is using more than 160 kbps for the mid channel of a joint stereo VBR encoding? At least in LAME 3.95 which I currently use, the VBR histogram only "shows" the total bitrate of each frame and whether or not that frame is encoded in M/S or L/R mode. It doesn't show me how much was dedicated to M and howmuch to S. I used LAME 3.97 briefly before and it has a much more comprehensive display, but I can't remember if it shows VBR histogram bitrates with M and S separately?

But for the issue of encoding a TRUE MONO wave sample (not near-mono Stereo WAVs, and perhaps not even a channel-duped Stereo WAV) in VBR mode, I very much agree that if you ever see LAME go over 160 kbps, great concerns should be raised. Ive never ever tried this myself so I don't know what happens. Have you tried, and does LAME vbr really go over 160 kbps for TRUE mono files occasionally/sometimes?

I'm not saying that analyzing encoder behavior with near-mono or pseudo-mono samples is invalid here, but I'd feel safer analyzing true mono files before drawing any firm conclusions.

I agree that I would never enforce a maximum bitrate of 160 kbps for a Joint Stereo VBR for near-mono content. But for a true mono content, I dunno. I guess it would depend on how often (or if) LAME vbrs go over 160 kbps for true mono files.

I had thought of both of these theoretical concerns you mentioned also, but I likewise don't really consider it an issue and never mentioned it, because I also have never encountered a sample where I heard anything noticeable. That doesn't mean that I am absolutely certain such effects can't be noticed, but I feel relatively confident that LAME's Joint-Stereo switching algorithm is conservative enough, and M/S psy-model and bit-allocation algorithms are accurate/applicable and generous enough for me. After all, many listeners have tested and I see no reason for me to disagree with their findings on this issue.

I am not as against Joint Stereo as my previous posts may have made it sound, though I tried to describe my views as accurately as possible. When I choose to encode CBR at medium bitrates, or VBR at any qual setting, I always use Joint Stereo. I even think Forced Joint Stereo can be quite good when implemented well. Even if there is absolutely no usable correlation between the left and right channels, if equal bits are allocated to the M channel and S channel, couldn't the quality still be as good as an L/R representation? (I've thought about this a long time but am still not sure, so I'm asking)

Are you sure about that? Suppose I have a song with vocals in the center, and a whole bunch of instruments/crap/drums on both sides at the same time (the typical situation for most music I listen to). LAME Joint Stereo will generally encode these frames as L/R, but for the moment lets suppose you used Forced Joint Stereo (which like I said just previously I'm not sure if it is a problem or not). What would a perfect encoder do in this situation, and what would the resulting quality be of the M channel, and what would the resulting quality be of the vocals in the center (which is not necessarily the same as the quality of the M channel)? I am thinking that the encoder should probably allocate equal bits to the M channel and S channel in this case. So the quality of the center vocals will be lowered due to the presence of the side instruments, wouldn't it? Furthermore, the M channel is defined as L+R/sqrt(2)....so the instruments/crap on both sides is a part of the M channel too. It's not like the M channel is just the vocals in the center. It still has the burden of encoding the added complexity of the side instruments (but they might be "softer" than the center, due to the weighting).

Furthermore as halb just said there may be questions as to how well the standard psychoacoustical models behave on a "mixed channel" which doesn't directly correspond to what is coming out of your speakers (but he is more concerned with the S channel, probably rightfully so).

I'm not disagreeing with the fact that psuedo-mono signals, or signals that are temporarily psuedo-mono, will benefit greatly from Joint Stereo mode...it's during these times that LAME switches to M/S mode. But when there is much stuff going on in the sides, I *don't* think that the center channel instruments/sounds/vocals benefit. But like I said in the previous post, I'm not sure the center stuff is 'hurt' either if equal bits are allocated to M and S.
I agree this is true for L/R mode, but it could also be true for M/S mode as well. Because the S channel is going to have some distortion as well, and the mp3 decoder has to add up the M+S channels to re-create the L/R channels for output to your soundcard. And the S channel distortion is going to get inherited into the L and R channels and the same thing will happen in the end. Actually, I think it could be argued that the center channel could be even LESS centralized in M/S mode compared to L/R mode, when lots of side instruments are present...if the encoder is too aggressive and uses too few bits for the S channel. I could be wrong about this. At the same time, near-central "sounds" might become overly centralized if too few bits are allocated to the S channel, too. To sum it up, I guess that insufficient bits for an S channel just makes all sounds have questionable spatial positioning. Sounds could spread out or contract in randomly, just depends on the randomness of the quantization noise at that instant. I could be wrong about this too.

Although I don't agree with your choices (they aren't right or wrong, it's just personal preference) I really like your analogy. In my case, at high bitrates I prefer to be 'defensive', that's all.

But as an aside, I also wanted to mention that Joint Stereo could potentially fix 'rare problem samples' with Forced Stereo also, it's not only the way you mentioned (actually, I never even mentioned problem samples with Joint Stereo, just to be clear). Namely, Joint Stereo could fix some pseudo-mono samples that are extremely complex and difficult to encode (but it wouldn't fix pseudo-mono problem samples that are problems due to fundamental, non-bitrate-related, codec issues). But like I said before my philosophy at high bitrates is that I may not even want to fix those types of problem samples, since I wouldn't be able to fix those same problem samples had the signal come from the side(s).

Truly uncalled for.

Hey, guys!
Please stop responding to gobbledygook aka pseudo-scholarly jabber. Yes, we know that author needs help, but probably we can't provide it.

Porcupine might have managed to come out with nonsense in some of his replies. I'm sure he'll continue to re-think things as he goes along, and might even agree with the HA wiki after a few years!

However, the impact of forcing this or that, when it could cause a problem, when it might be beneficial etc is fair debate.

Of course JS is vastly superior - that's why it's the recommended setting. Of course VBr is vastly superior - that's why it's the recommended setting.


But have you ever tried karaoke or fake surround with a VBR JS mp3? If you had, you might have some interest in this discussion!

Cheers,
David.




Here is the first file I tried. It's bit-identical dual mono, made by taking the left channel of a supposedly mono track, and copying it to the right channel...



2.3% of frames are over 160kbps. 100% of frames are MS.

In the bitrate histogram, * means an MS frame, % means an LR frame (there are none here).


Just to re-iterate, unless you have specific concerns to address (e.g. karaoke, surround) JS is by far the best option with lame. Forcing discrete stereo clearly has the potential to harm quality, and we know it can waste bits (the above file will jump to 200kbps and have lower quality!).

Using CBR is similarly perverse if you're aiming for quality. If you don't trust the psy model, VBR with an enforced increased minimum bitrate makes more "conceptual" sense.

Cheers,
David.

sorry about being absent ... my KT333 mobo finally bit the dust and then i jacked up this mobo installing the HSF. and linux doesn't seem to like dualmonitor (or at least dual monitor with this vid card), so anywho:

this is incorrect when posed with the situation i pose in the OP. in a situation where you're just going to use 2 speakers, 1 pair of headphones, i'm sure it's going to be *perceptually* lossless, but my experience with 3.90.2's inflated bitrates and 3.96, it was not lossless in my situation.

this i don't question.

this is probably a moot point as i found i could maybe ABX 1 of the first 10-12 samples from the 128abr.

do you use KB 5.1 or an amplifier that matrixes 2.0 audio into more than 2.0 sound? if not, this thread isn't entirely for you...

i might pose the same question for Porcupine, even though a bit of what he's pointed out (as well as the other contributers to the thread) has given me some addition material to think of.

i too haven't tried --nssafejoint recently, and i'm just about to try it right now. 3.97 HAS improved a lot. JS at low bitrates (a near-128abr -V setting) and -V 2 are almost not painful to hear anymore with electronica music, although it sticks out a lot more with more acoustic music (Roxette's Tourism came to mind from my latest set of encodes i need to redo).

i'm not sure i'll focus too much on dual mono/mono encodes, but i'll definintely try the one setting we were messing around with a few years back...



the humbling experience of ABXing 128abr in a 2.0 setup leads me to say that as long as the quality isn't below (the near) 128abr (V setting used in that test) in the rear channels (or front for that matter), i'm sure i'll be ok.

--nssafejoint alone doesn't make a difference. 2BD, was it the lower it got, the more it used L/R opposed to M/S? i'll have to write up a batch tomorrow and encode (and rename) 10 WAVs in one fell swoop. i've just encoded and hand-renamed a bunch -V2-4 JS, Stereo, and -nssafejoint with no other switch...? (passing out now...)

plonk,

Check nssafejoint is enabled in the compile you have. It'll tell you if it's unknown/disabled in the command window before encoding if you supply it on the command line.

I was caught out by this with another switch recently - a lot of the "testing" options are disabled in betas these days. No sure if nssafejoint falls into this category.

Cheers,
David.

P.S. does vbr-new use it anyway? I really should pay attention.

well, the size seems to be indentical to the kilobyte. i'll have to look at the actual size to be sure, both for -vbr-new and -vbr-newless. so yeah, both seem to use --nssafejoint.

i did a quick test just now (have to leave for work) with nero's aac encoder. quality 0.8 was massive (anything over 300kbps really should just be losslessly compressed imo). quality 0.5 yielded a 180kbit file just about and it sounded quite good with regards to surrounds. i'll have to try a handful of settings tho. even if MP4 does have superior bitrates to mp3 and retain surround info, i'm sure i'll stick with MP3 until every DSP device i own supports MP4... (and erm "downloads" come in MP4, too)

"trial music" ... but that's a whole other argument (every single last one of my music purchases were based on trials)

Some people in this thread badly need some education on the definition of the term "philosophy". There is so much desinformation, mangling of meanings and logical fallacies about this term in this thread, that i'm not even motivated anymore to debunk them. Proposal: unless you know exactly what "philosophy" means, dont use that term at all.

- Lyx

Okay, I'm back from doing a lot of similar tests with my Lame 3.95.1 (standard executable that I downloaded, not compiled myself, to assuade any worries). I tested a variety of VBR modes, mainly with the old VBR algorithm, not --vbr-new (since I usually encode with the old VBR, and it's not the default until 3.97 I believe). I discovered a number of weird oddities that I think throw many things into question. I also did some testing with --vbr-new (although I didn't save the logs, the logs I saved are already too much) and while the outputs were fairly different overall, the same "oddities" and important issues did not change.

plonk420, I rarely listen to my music using various surround sound methods, but who knows I might do it more often in the future. Plus, my philosophy is to encode not only for my own ears and listening habits, but for the habits of others too, so the way you listen to music would concern the way I encode my own files, as well. If Joint Stereo caused you problems, AND I couldn't ABX for myself any worsening of quality if I chose to encode in Stereo, I might encode in Stereo in case I ever share my music with you or people like you.

Anyways plonk, if you feel I derailed your thread somewhat, I apologize, and hope to make it up to you now with my new weird finding #1...regarding these --nssafejoint questions I did a bunch of tests. It appears that for VBRs with V5 and higher (lower quality) settings, "nssafejoint" is defaulted to off but can be turned on with that switch. There's nothing in the LAME verbose output that says if nssafejoint is on or off, but the VBR histograms and final L/R vs M/S frame counts obviously show when it is on or off.

Now the weird thing. At the higher quality settings, from V4 up to V0, the --nssafejoint switch can be written on the command line, and LAME will not complain or give any error warnings, but the switch has absolutely no effect on the output. NONE. Furthermore, nssafejoint is STILL defaulted to be off. But as one increases the VBR quality setting, the default Joint Stereo "safetyness" of LAME becomes more and more safe. It's not just a Safe vs Unsafe thing, there is a slow progression where the higher quality modes have more and more L/R frames. At V1, the default Joint Stereo "safetyness" is pretty much identical to enforcing --nssafejoint on V5, V6, etc. At V0, the Joint Stereo "safteyness" is more safe than --nssafejoint.

But at V4 and V3 and V2, which is what you are encoding at, the Joint Stereo settings are quite aggressive, and again "nssafejoint" is NOT on, nor can it even be turned on. This may explain why you notice stereo separation issues in the surround channels. !Perhaps your issues would go away if you used V1 or V0 Joint-Stereo instead! Anyways, I hope this helps you. The logs will follow shortly.

I also found another interesting things in my tests. I encoded 2 different songs, one with a relatively high degree of stereo separation and no vocals (but still with a lead instrument in the center) which is called Track03.wav in my logs, and another one with moderate or below average stereo separation and center vocals which is called Track01.wav in the logs. I lopped off the beginning and ending seconds of these songs to get rid of silence, then encoded them both as CBR 320s and VBR V0s. BOTH these songs ended up with 100% L/R frames, not a single M/S frame (not even in the smaller VBR frames). In the past I had encoded a bunch of V0 samples and had a reasonable amount of M/S frames for the smaller VBR frames (still at V 0) and just a tiny tiny handful of 320 kbit Joint-Stereo M/S frames...but those were all samples of someone just talking with little to no BGM, highly pseudo-mono (but not perfectly mono) files. This was the first time I tried to encode normal songs with average stereo separation, and my finding was that absolutely no frames are ever encoded in M/S mode ever in any of the songs I tried....anyways this just encourages me to use Forced Stereo all the more on my 320 CBRs.

C:\Program Files\Lame395>lame -h -V 0 d:\lists\Track03cut.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding d:\lists\Track03cut.wav to d:\lists\Track03cut.wav.mp3
Encoding as 44.1 kHz VBR(q=0) j-stereo MPEG-1 Layer III (ca. 5.7x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7504/7506 (100%)| 0:15/ 0:15| 0:15/ 0:15| 12.621x| 0:00
128 [ 2] %
160 [ 148] %%%%
192 [ 902] %%%%%%%%%%%%%%%%%%%%%%%%
224 [2254] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
256 [2484] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
320 [1716] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
average: 251.4 kbps LR: 7506 (100.0%)

C:\Program Files\Lame395>lame -h -V 0 d:\lists\Track01cut.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding d:\lists\Track01cut.wav to d:\lists\Track01cut.wav.mp3
Encoding as 44.1 kHz VBR(q=0) j-stereo MPEG-1 Layer III (ca. 5.7x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3070/3072 (100%)| 0:06/ 0:06| 0:06/ 0:06| 12.548x| 0:00
32 [ 1] *
128 [ 2] %
160 [ 21] %%
192 [ 142] %%%%%%%%
224 [ 569] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
256 [1065] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
320 [1273] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
average: 272.8 kbps LR: 3071 (99.93%) MS: 2 (0.06508%)

C:\Program Files\Lame395>lame -h -V 2 d:\lists\Track01cut.wav --nssafejoint
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding d:\lists\Track01cut.wav to d:\lists\Track01cut.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3070/3072 (100%)| 0:08/ 0:08| 0:08/ 0:08| 9.9659x| 0:00
32 [ 1] *
96 [ 3] %
112 [ 4] *
128 [ 40] %**
160 [ 536] %%%%%%%%%%%%%%***************
192 [1238] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%******************************
224 [ 847] %%%%%%%%%%%%%%%%%%%%%%%%%*********************
256 [ 323] %%%%%%%%%%%*******
320 [ 81] %%%**
average: 204.3 kbps LR: 1654 (53.82%) MS: 1419 (46.18%)

C:\Program Files\Lame395>lame -h -V 5 d:\lists\Track01cut.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding d:\lists\Track01cut.wav to d:\lists\Track01cut.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3070/3072 (100%)| 0:10/ 0:10| 0:10/ 0:10| 8.0196x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 1] *
80 [ 0]
96 [ 13] *
112 [ 331] %***************
128 [1143] %%%%%*************************************************
160 [1408] %%%%%%%%%*********************************************************
192 [ 146] %%*****
224 [ 29] %*
256 [ 1] *
320 [ 0]
average: 144.7 kbps LR: 315 (10.25%) MS: 2758 (89.75%)

C:\Program Files\Lame395>lame -h -V 5 d:\lists\Track01cut.wav --nssafejoint
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding d:\lists\Track01cut.wav to d:\lists\Track01cut.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3070/3072 (100%)| 0:10/ 0:10| 0:10/ 0:10| 7.8724x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 1] %
80 [ 0]
96 [ 2] %
112 [ 91] %%%%
128 [ 938] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
160 [1808] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
192 [ 163] %%%%%%
224 [ 63] %%%
256 [ 6] %
320 [ 0]
average: 151.9 kbps LR: 3008 (97.88%) MS: 65 (2.115%)

Looking at the log above there are also a number of other oddities. Weird thing #2, there appears to be a potential bug with LAME, in that the very first frame and the very last frame of a file are forced to be an M/S frame no matter what. Note that my Track01cut.wav has exactly 2 M/S frames, when I said there were 0. However I re-cut this file in different positions about 10 times, and each time there was exactly one 32 kbps M/S frame at the very end of the file, and exactly one M/S frame (at 160 or 192 kbps, it depends randomly on where I cut it) at the very beginning...you can't see it in the histogram because it gets swallowed up statistically but in realtime I see it before it disappears. Then the rest are all L/R. Yet for Track03cut.wav there were exactly 0 M/S frames (as long as I cut it, if I didn't cut it then there are like 50 M/S frames of silence all at the end). I have no idea why.

In any case, this shows there may be some bugs with LAME and we should generally be willing to ignore any 1 or 2 "scary" frames we might see (that might be 320 kbits M/S mode...perhaps we could even discount 1 or 2 "scary" 192 kbits frames for mono files because they might be bugs too).

But that's not a big deal, just one tiny insignificant glitch. More interesting is weird thing #3....look at the V2 sample log above. There are a significant number of those "scary" 320 kbps M/S frames. But at V0, those don't exist, as LAME *chose* to encode in L/R mode. So are these 320 kbps M/S frames really problems? We also know that these "typical songs" I chose are considered by LAME to have a high degree of stereo separation, so much so that 100% of the whole song is L/R frames anyway at V0 and 320 CBR. So for those songs when at V2, even when LAME encodes any frame at all as M/S, we can be relatively certain that the encoder is "grasping at straws" so-to-speak, and most likely had to allocate approximately equal bits to M and S regardless, therefore offering potentially little to no gain in quality.

What I would say is STILL a problem, or "scary" frame though, is if one encoded a psuedo-mono file at V0 (not any lower) Joint-Stereo and then still saw a 320 kbps M/S frame. Or perhaps if one encoded a more typical file that somehow had a V0 320 kbps M/S frame that may or may not be a concern (even then, it's unlikely to be a concern due to the unsolid but "hopeful" arguments I posted way back). But I think histogram results from V2 and possibly V1 encodings should not be considered, ever, because of these weird findings.

None of us use v3.95, Porcupine. You've done no valid statement about quality so far.



Stereo coding is up to the track you are encoding. Try the sample I've posted. Most of frames would be M/S regardless bitrate.

One sample (rosemary) that shows middle vocal leads to M/S frame. Please check the JS type while you are listening.


Encoder: LAME v3.97 (-V2 --vbr-new).

But just to be clear, I'm NOT trying to refute what 2Bdecided posted earlier in his log. The concerns are still totally valid, we just have to test and consider what we and LAME are doing more carefully. I next did further tests, that duplicate 2Bdecided's results well, yet also raise even more questions about what we can take from LAME's VBR histogram displays. I took Track01.wav (the one with the vocals and less stereo separation) and made it into a mono WAV file by mixing the channels. Then I took that mono file and duped the channels and made a Stereo Duped "mono" WAV file out of it.

C:\Program Files\Lame395>lame -h -V 5 d:\lists\Track01mono.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding d:\lists\Track01mono.wav to d:\lists\Track01mono.wav.mp3
Encoding as 44.1 kHz VBR(q=5) single-ch MPEG-1 Layer III (ca. 11.9x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3597/3599 (100%)| 0:06/ 0:06| 0:06/ 0:06| 14.811x| 0:00
32 [ 83] ***
40 [ 5] *
48 [ 19] *
56 [ 142] *****
64 [ 904] *****************************
80 [2088] ******************************************************************
96 [ 269] *********
112 [ 67] ***
128 [ 22] *
160 [ 1] *
192 [ 0]
224 [ 0]
256 [ 0]
320 [ 0]
average: 75.8 kbps

C:\Program Files\Lame395>lame -h -V 5 d:\lists\Track01dupedstereo.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding d:\lists\Track01dupedstereo.wav
to d:\lists\Track01dupedstereo.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3597/3599 (100%)| 0:07/ 0:07| 0:07/ 0:07| 12.822x| 0:00
32 [ 72] **
40 [ 5] *
48 [ 7] *
56 [ 38] **
64 [ 446] *************
80 [2423] ******************************************************************
96 [ 496] **************
112 [ 81] ***
128 [ 27] *
160 [ 5] *
192 [ 0]
224 [ 0]
256 [ 0]
320 [ 0]
average: 80.1 kbps MS: 3600 (100.0%)

So, at V5 level of quality there are no problems. We can be confident this sample can be safely encoded as 320 kbps Forced Stereo (well, in this case it doesn't matter as the Forced Stereo and Joint Stereo output is identical, but we can pretend it wasn't).

C:\Program Files\Lame395>lame -h -V 2 d:\lists\Track01mono.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding d:\lists\Track01mono.wav to d:\lists\Track01mono.wav.mp3
Encoding as 44.1 kHz VBR(q=2) single-ch MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3597/3599 (100%)| 0:05/ 0:05| 0:05/ 0:05| 16.660x| 0:00
32 [ 55] **
96 [2861] ******************************************************************
112 [ 430] **********
128 [ 171] ****
160 [ 70] **
192 [ 10] *
224 [ 3] *
256 [ 0]
320 [ 0]
average: 100.1 kbps

This result is fairly similar to what 2Bdecided got. There are some 192 and 224 kbps frames which could potentially be a problem for 320 CBR Stereo files, although the amount is so few perhaps it could be ignored.

C:\Program Files\Lame395>lame -h -V 2 d:\lists\Track01dupedstereo.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding d:\lists\Track01dupedstereo.wav
to d:\lists\Track01dupedstereo.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3597/3599 (100%)| 0:06/ 0:06| 0:06/ 0:06| 14.811x| 0:00
32 [ 53] ****
96 [ 831] ****************************************************
112 [1061] ******************************************************************
128 [1026] ****************************************************************
160 [ 559] ***********************************
192 [ 70] *****
224 [ 0]
256 [ 0]
320 [ 0]
average: 120.7 kbps MS: 3600 (100.0%)

This is kind of similar too, but upon closer inspection there are some weird things that throw this kind of analysis into question. One, why is the Duped Stereo file 20% bigger than the True Mono file? Two, what happened to our 3 worst-offending 224 kbps frames? They seem to have mysteriously gotten better and gone away. Maybe this can be explained by the bit reservoir. Overall the Duped Stereo file is bigger and there are far more 192 kbps frames...perhaps this fills the reservoir faster and made no need for those 3 bad 224 kbps frames. But this still doesn't explain why overall the Duped Stereo file is so much bigger than the Mono file.

C:\Program Files\Lame395>lame -h -V 0 d:\lists\Track01mono.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding d:\lists\Track01mono.wav to d:\lists\Track01mono.wav.mp3
Encoding as 44.1 kHz VBR(q=0) single-ch MPEG-1 Layer III (ca. 5.7x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3597/3599 (100%)| 0:04/ 0:04| 0:04/ 0:04| 20.251x| 0:00
32 [ 53] **
128 [2747] ******************************************************************
160 [ 733] ******************
192 [ 67] **
224 [ 0]
256 [ 0]
320 [ 0]
average: 134.3 kbps

True mono, highest V 0 quality. No higher quality can be gotten. File is much bigger than even the V2 stereo duped file. But strangely enough, there are zero 224 kbit frames again, and oddly enough there are even less 192 kbit frames than in the V 2 stereo duped file.

C:\Program Files\Lame395>lame -h -V 0 d:\lists\Track01dupedstereo.wav
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding d:\lists\Track01dupedstereo.wav
to d:\lists\Track01dupedstereo.wav.mp3
Encoding as 44.1 kHz VBR(q=0) j-stereo MPEG-1 Layer III (ca. 5.7x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3597/3599 (100%)| 0:05/ 0:05| 0:05/ 0:05| 16.894x| 0:00
32 [ 48] ***
128 [ 759] **********************************
160 [1483] ******************************************************************
192 [1201] ******************************************************
224 [ 109] *****
256 [ 0]
320 [ 0]
average: 164.2 kbps MS: 3600 (100.0%)

Duped stereo apparently makes LAME go berserk in this scenario. Huge portion of the entire song rises above 192 kbps, when it shouldn't have to.

I dunno, these results are odd. I fully agree that there can potentially be mono/single channels that require more than 160 kbps to encode transparently at times. But do our test samples really contain such times? How much can we trust these histograms to tell us how many bits we really needed? And even if we could trust these "mono" histograms, when encoding typical stereo files in Joint Stereo VBR the histogram could be next-to-useless.

Oh yeah, I should mention the songs I used. I am using the opening vocals theme song and the main BGM theme song for an anime cartoon called Fate/Stay Night.

None of my statements are proven to still exist in 3.97 sure (although the LAME history changelog makes no statement about changes in these areas). I believe I my statements are still very valid so far. They are surely valid for LAME 3.95. Feel free to test for yourself if they remain valid in 3.97, I would be interested to know also. You don't have to use my samples, I'm sure any song with reasonable stereo separation would be useful.

I notice that in your graph you used -V 2, which as I just said has "nssafejoint" stuck to OFF, so your graph is totally expected and completely consistent with the results I got myself.

Oh yeah, if you do decide to test 3.97 for me/us you should probably use the "-q 3" switch like 2Bdecided did not the "-h" (q 2) switch because the -q switches were remapped for LAME 3.97 and my -h is equal to your -q 3 (I tested this earlier, before erasing my LAME 3.97). I guess -q 3 is also the default for -V 2 in LAME 3.97, but the default for -V 0 may be something else. It probably doesn't matter either way but just in case it does....

Maybe you even have the same CD I do, since you probably like Hare+Guu maybe you like Fate/Stay Night too. I got my songs off the regular standard OST for it.

Porcupine, do you really think when going into more and more such details you get a helpful answer?
Audio data bit rate is what counts, not the displayed bitrate of the transporting frame, and even audio data bitrate doesn't tell the whole story.

I think the most important thing is to realize: the developer's job consists of decision making to a great extent, and the same is true for us users when we have to decide for an encoder to use. And there are no universal benefits. Any decision that is good in one case can be bad in another case. What it's up to decide is: what is the best compromise? After all we're in a world of lossy encodings (though of very good quality).

If for theoretical reasons you are afraid of using joint stereo: go ahead and use plain stereo, and compensate for the drawbacks by using extremely high bitrate. You do that as you use CBR 320, and everything is fine. You can find evidence for that looking at Serge Smirnoff's 320 kbps test on www.soundexpert.info where Lame 3.90.3 gpsycho plain stereo CBR 320 is tested as well as 3.97 nsypsytune joint stereo CBR 320, and both encoders came out on par.

But your problem is that you are not just afraid of joint stereo, but also of lowpassing, ATH behavior, and may be more. You can easily compensate for not using joint stereo by using CBR 320, but if you decide to use -k, specific ATH settings, and may be more you end up using a very crappy encoder setting, and CBR 320 can't compensate for that all.
So your kind of decision making is pretty dangerous and this is remarkable especially as it is not based on any real problematic encodings but on just very theoretical thinking.

I think mp3 can be only justified as the right format for you if compatibility is of great concern to you (which I doubt it is).
My impression is Lame gives you a basis for theoretical considerations and the possibility to implement your considerations by making intensive use of the many settings which Lame offers. I guess this pretty unique feature of Lame is what makes Lame so attractive to you.

In your ATH/lowpass thread I suggested you use wavPack lossy. Stimulated by shadowking's new 350 kbps fast mode usage I started to do some listening tests again, and I can tell you: in the 300...400 kbps range you'll be absolutely happy. All your mp3 considerations are meaningless here, all you have to fear is extremely small added noise which usually is inaudible (and even in the rare cases where it's audible it's not annoying).
The against CBR320 mp3 better 320 kbps wavPack lossy alternative is a wavPack setting like -hb320x5s0
which means: high quality mode, target bitrate of 320 kbps, extended encoding effort of x5 degree, no noise shaping.
-hx5 means encoding will last a very long while, but if this doesn't bother you you can even consider using extra-high quality mode (use hh instead of h). If it lasts too long you can consider using x4 or even x3 instead of x5, or use normal quality instead of high (leave the h off). High quality mode and highly extended encoding effort are of real benefit only on rather rare occasion at 320 kbps. You can compensate for dropping high quality settings by using a higher bitrate, use for instance
-b350x5s0.
My advice is to use s0 (no noise shaping). The default noise shaping can have benefits, but according to my experience in those cases where the default noise shaping is bad it is a lot worse than no noise shaping at all cause usually it occurs in the mid frequency range then where it can be easily heard by our ears and moreover it doesn't sound like what we are used to consider as noise. It's pretty obvious at a rather low bitrate like 250 kbps. At ~ 350 kbps things aren't very remarkable any more however.

Also Ghido's Optimfrog Dualstream is really worth checking out if you can put up with slower decoding (monkeys audio speed). True VBR modes, fast encoding, no joint stereo, ATH, lowpass etc. Only artifact is pure flat white noise like wavpack can be auto-shaped to second order when using --ans

Quality 3 ANS will handle virtually anything resulting in 345k :

--encode --mode fast --optimize none --ans --quality 3


Anyway Halb27 is right : Different encoders are strong at different things and its generally a bad idea to disable psy features on mp3/mpc/aac

halb, I PM'ed my response to you so that plonk420's thread wouldn't be derailed any more than necessary.

To everyone, I discovered a major error with my previous testing, though it should only affect a couple of the results. I noticed that the Left and Right channels on my test WAVs were reversed for some stupid reason. After hours of troubleshooting I realized that my CD Drive (this is a new computer, I only started using it for ripping a month ago) randomly swaps the channels when it rips audio with Exact Audio Copy (Secure Mode) which EAC does not report or notice. After digging through all CDs I ever ripped with this comp, it seems to happen 25% of the time, completely randomly. This sucks ohwell, the only good thing I can say is that at least if the CD rips backwards, the whole CD is backwards. If not for that, I'd be rolling in hell right now since I'd have to redo everything I ever encoded with this comp. I re-ripped the same exact 2 songs and this time they were normal.

Then it bothered me why such an idiotic thing would happen randomly and a major worry occured to me, which turned out to be true. I think my CD drive is sometimes skipping the first sample of the first track every time I put in a new CD. This not only reverses the channels but causes them to be time-misaligned by 1 sample. I can't really hear that, but it might be enough to prevent LAME from applying Joint Stereo properly.

When I re-encoded my fixed files with LAME, they DID get a lot more Joint Stereo M/S frames. The vocal track with below average stereo separation now got 10% M/S frames in V0 mode (0 M/S frames before). The BGM track got 5% M/S frames in V0 mode. So Joint Stereo is still pretty helpful at V1 and V0 even with nssafejoint on (or something like it).

Although, this allowed me to discover that CBR 320 has an even more conservative stereo "safetyness" than V0. With -b 320, the vocal track had 0.5% M/S frames (18 frames total), and the BGM track had 1 M/S frame . I re-tested most of the things I show in the logs above and the results are still valid, though. The main changes are that typical songs have more M/S frames than I previously thought (although they could still have none at 320 CBR), and that statement I made about LAME possibly having a bug at the beginning and end of a file where there are 2 M/S frames may be untrue (since I fed it "bad" samples, although the bug could still be real I dunno).

Anyways, I have to go and re-rip 5 backwards CDs now. Argh. I am sad.

What brand is your defective CD drive, Porcupine?
I'm just curious.
Edit: this is supposed to be in reply to Porcupine's latest post.

Any encoding comparison that involves re-ripping a CD is flawed IMO unless you use AccurateRip. But why re-rip? You should rip to .wav once, and then use that same .wav file for each encoding.


JS of dual mono does yield a higher bitrate than encoding single channel mono of exactly the same audio - it's being discussed here...

http://www.hydrogenaudio.org/forums/index....46290&st=25

Cheers,
David.

2Bdecided, yeah I saw your thread on that even before this entire discussion started here. I am/was hiding from speaking in there though, as it seems the issue is still under current discussion and Gabriel is obviously a busy person and needs time to look into it further.

I agree with these things said there: That in the Joint-Stereo (duped channels) version of the same file, the "M" signal is sqrt (2) times louder than in the true Mono version, and this can possibly increase the size of the file. Also, like Gabriel said, that alone still shouldn't really make the file much larger except due to an effective shift in the ATH.

The thing that I question is that...I believe there is no way an effective shift in the ATH of 40% can increase the size of a file by 20% in the end. Well, any one of us could maybe test this by repeating these tests with the --noath option and see. I suspect we will still see a similar size increase though in the Joint-Stereo version, although it might be a little less drastic. Though it's also possible we might even get the opposite effect, as --noath may break the S channel's ability to detect perfect silence. I'm happy leaving it up to Gabriel if he wants to continue investigating.

The reason I believe this is that in general, I have not noticed that a softer file is THAT much more easily compressed than a louder file. When I listen to VBRs in general, as the song ends and it starts getting REALLY soft, I still don't see the bitrate drop at a similar pace. Usually what I see is that the bitrate drops only a little bit, if at all, to around 128 kbps to 160 kbps...then it really insists on staying there until the song truly hits dead silence and suddenly the bitrate is 32 kbps (due to the silence frame bitrate that LAME uses). If moderate volume changes of 40% amplitude made that much difference, VBRs should drop fairly linearly down to 32 kbps as a song ends, but they don't (btw I've also used the -b 32 switch to check this).

So I basically suspect there is a different reason (which I don't know what it is) causing this (not the 40% louder amplitude of the M channel), and until that reason is determined I will remain suspicious of some things.

BTW, yeah an encoding comparison where I re-ripped each time would be flawed. I did NOT do that nor do I ever do that. I rip once then re-encode the same file each time.

I only re-ripped ONCE after I discovered my CD drive had messed up the first time. Then I re-did all tests with the fixed up wave files (none of those logs are posted, as I already said, but I mentioned the results).

fj4, I dunno, I bought this relatively new (and cheap) computer several months ago, and like most of the non-upperend machines these days everything is OEM and I can't find any info on source brands on practically any components inside this thing (except for the stuff like CPU, Graphics Processor...stuff like Sound Card it's all onboard integrated and I don't even know, even though I tried hard to find out). I can tell you the weird model number that Exact Audio Copy shows, it's HL-DT-STDVDRRW GSA-H20L and my computer is a Compaq Presario desktop Athlon 64 3500+ processor.

So far I managed to re-rip and encode 2 of my CDs I need to do and learned some more things about my buggy CD drive. It's no coincidence these CDs ripped backwards because it's certain CDs that my drive wants to rip backwards (25% of all CDs, apparently). When I re-rip they still tend to be backwards unless I try many times (I was "lucky" with my test CD, it ripped correct on the 2nd time). There's nothing special about the CDs my drive doesn't like, they aren't scratched or different from my other CDs in any way.

Usually those same CDs will play correctly if I play them directly with other programs, but not always. The first time I try to re-rip with EAC though, they are likely to become backwards. If I set the option to "spin up drive first" they are much more likely to rip correctly but not guaranteed, as well. And once the first rip starts, all tracks on that CD will rip the same and my CD drive gets "stuck" forever in the way it has decided to be. If it decided to be backwards at that point it will always be backwards, even if I quit EAC and play the CD directly with a different program. If it decided to be correct it will always be correct. And this can only be unstuck by ejecting the CD physically and putting it back in again. Weird.

Also, a bit more testing with LAME leads me to believe that even with my fixed files, that 0 or 1 or 2 M/S frame bug at the beginning or end of any mp3 still exists. I encoded some different (ripped correctly) songs from other CDs and cut them, etc, and that phenomena still seems to occur sometimes (dunno why it only occurs sometimes). So my original Track03.wav probably does have 0 M/S frames even in the fixed version.

And I don't know if anyone noticed but in my logs, it seems like LAME can't add because the reported # of M/S frames and # of L/R frames is 1 bigger than the # of total frames. Sometimes that happens and sometimes it doesn't, that is weird too. It can happen on both my backwards files and correctly-ripped files, I tested a bunch of files. Also when LAME ends it writes something like 6687/6689 (100%) in the frame counter, it's always 2 less than the total. It always does that though on all files so it's not a real glitch of any concern, just a screen output oddity. But the M/S + L/R = Total (+1 frames only sometimes) is a bit odd because it's not always that way, depends on the input file, but not on any attribute of it that I can see.

Have you tried 3.97 yet? Certainly the total number of frames reported is correct here.

Maybe try one of those PC stressing programs to check your CPU is working perfectly. You're not overclocking, are you?

Cheers,
David.

Looking at your 3.97 log, yeah you're right lol. That's reassuring (for 3.97, not 3.95). Oh well. Yeah I already wrote I tried it briefly but erased it and decided to stick with 3.95, for various reasons. I'm not one to follow the 'recommended settings and version' of a forum consisting of people I don't know, and who don't explain to me why a version is better. Just saying 'a large number of us tested it carefully and we say this is the best' doesn't convince me at all. I either need technical explanations why something is better, or I need to have experienced that something is better myself.

I doubt my CPU is the issue. Anyway, I'm not a computer geek and I have never overclocked anything, and barely even know how to open the case on my computer. I install minimal amounts of software...I use the computer mainly for simple tasks...it's mainly a Music Box really. I guess I also type things on it. And look at pictures. That's all. I hardly ever run any games, I don't program things, and I don't really need CPU speed. The most abnormal thing I do is that when I bought this computer, I erased 75% of the add-on worthless software it came with, such as RealPlayer, Rhapsody, Xing mp3 Encoder, Use Ebay Now!, Use AOL Now!, etc utter garbage.