I use EncSpot to analyse my mp3 files. It displays a bunch of graphs. However, I never figured out how to interpret the Joint-Stereo graph. I'd like to know how much Joint-Stereo is used in the file and therefore if Joint-Stereo resulted a lot space savings or not. So what do I have to look for? It gives me graphs for 'ss' ; 'is' ; 'ms' and 'mixed'.

Let's say, I have a file that uses 92,5% ms and 7,5% ss does this mean that many frames contained the same information so that Joint-Stereo could actually take advantage of that...

thanks

Joint Stereo can make use of Simple Stereo (SS) frames, Mid/Side (MS) Stereo frames, Intensity Stereo (IS) frames and Mixed frames.

On Simple Stereo frames, bits are reallocated between channels if one channel is more complex than the other.
On Mid/Side Stereo frames, a middle and a side channel is created. The middle channel stores the common audio and the side channel the difference between the two. The side channel is coded using less bits than the middle channel. This method is lossless.
On Intensity Stereo frames (usually for low bitrates and FhG encoders), the left and right channels can be combined by saving some frequencies as mono and placing them in the stereo field based on the intensity of the sound. This method is lossy.
I am not sure what mixed is, though. Is it possible to apply one type of Joint Stereo on a group of subbands and another type to the rest of the subbands?

Encspot cannot tell you how much space was saved. You could re-encode with the same command line but switch to -ms, then compare file size.

Last I ever bothered to check this was with Lame 3.86 and the average saving was about 15kbps at V2.

thank you for this great explaination! So to come back to my original question...it is not possible to tell from any of these graphs how efficiant JS in a certain file was. The only way to get an idea would be to encode the same song in --preset standard twice using Stereo and for the second file Joint-Stereo...

Also, LAME never uses Intense Stereo...I guess that's because it's lossy...so why does Lame even offer a Stereo-Mode? I would just rename Joint-Stereo to Stereo and get rid of the 'plain' Stereo mode. Lame shouldn't allow to encode a file using unsafe JS either...well, and CBR modes should be dropped as well. People that still use CBR will be perfectly fine using LAME 3.96.1...besides that, I don't think that many improvements are made in CBR...I know, there are supposed to be some old mp3 players around that don't play VBR files...I say, screw them since such a piece of crap doesn't even deserve the name mp3Player! All recent mp3 Players that were released within the last 3 years should support it anyway...so the development should focus on the vbr-modes....

"...so why does Lame even offer a Stereo-Mode?"

It helps to rule out suspected joint stereo artifacts.

Its much faster.

There is still a lot of misinformation about joint stereo out there. Many will not use it still, and I would still rather have a Lame -ms file than a lesser encoder.

Most of the stuff I get from Winmx is CBR 192 -ms still, although Lame VBR is starting to show up more and more...........

I agree. Isn't that what AAC do?

Lame's Jont-Stereo is safe...unless you use unsafe Joint-Stereo...which should be removed as well.

how much faster?

that is what I'm saying...so that's why Joint-Stereo should be renamed to Stereo...the name is a bit confusing...


well, that is probably because release groups are too ignorant and too stupid to do some research. Someone would assume that some of their members should know better...

As far as speed goes it was around 10% on abr IIRC.

As far as the other, I hear what you say. In some circumstances it would be best to remove options from less experienced users and default to the best settings. The preset system has helped with this but there are still plenty of people using their own command lines.

I think the release groups are still just giving people what they want, and lots still think -mj is bad.

By the time they are all educated, we may all have Ipods and use aac.

exactly! In the past there have been quite a lot questions about command-lines...most of them were awful...


I don't think so. Joe Average won't know if it is Joint-Stereo or not. He probably uses Stereo for his files but won't have a tool that tells him...otherwise he must have come across some true information about JS...

I do have an iPod but I still don't use AAC. It needs too much battery + since it doesn't have a VBR mode it won't safe me anything compared to --preset standard. I don't think Apple will ever implement a VBR mode...people are happy with 128kbps CBR...also, Apple's AAC won't play on anything else than the iPod, which sucks. That way Apple get's away with a much more expensive product in the future...I don't think most people that buy songs off iTunes are realizing that there are stuck with Apple forever...unless Apple get's sued and is forced to allow other companies to support Apple's AAC files....just imagine Microsoft would do that...it would be outrages...but Apple get's away with it

Bear in mind that you will save space when encoding in VBR mode. When encoding in CBR mode, both files (Stereo and Joint Stereo) will have exactly the same size.

No, thanks...


on-topic:

"mixed" is just a combination of M/S stereo and Intensity Stereo.

Intensity Stereo is only used for upper frequencies. Lower frequencies can be coded as L/R channel pair or M/S.


SebastianG

Is the "divider" set as standard, or can the encoder define which frequencies to code with IS and which ones with MS?

Very few of those points are actually true

My ipod works fine with AAC VBR. I'm using it now. If yours doesn't, send it back and ask for one thats not broken

I also proposed "ignoring" the stereo switch (along with some other switches) in another thread a while ago to the lame devs. For the same reasons:

1. besides of CBR its the most often made mistake - so a quality-hazard. The stereo-myth is just too strong to be fought with education - the only way to solve the problem is by ignoring the switch(mapping it to the default joint-stereo)
2. The encoder should decide which switches are best - user-preferences should only be available in stable builds when they apply to non-testing and non-dev tasks.

The answer which i got from gabriel if i remember right was:

LAME 3.9x is all about backwards-compatibility - lame4 in turn may see changes

- Lyx

Quoting from the relevant part of the publicly available final draft of ISO 11172-3:


So, the encoder can select a lower scalefactor band bound where he whishes to start using intensity stereo by signalling appropriate settings for 'big_values' and 'count1' for the 2nd channel leaving a certain 'zero_part'.


SebastianG

edit: typo

really? Like what?


I didn't say that the iPod won't play vbr AAC files, all I said was that Apple's AAC doesn't have a vbr mode...and according to the AAC listening test Apple's AAC is the best compared to other AAC implementations...
And to make an AAC file sound transparent you probably need approx. 180-210 kbps...so figure AAC CBR 210 against --preset standard LAME. Won't save you much...+ needs more power + iPod is the only player that plays Apple's AAC files...

It is odd that no one mentioned that the main idea behind joint stereo in LAME is quality improvement, not space savings.

There's no evidence suggesting AAC drains the iPod battery faster, read the Mac mags which have done their own testing to see this; Apple IS working on VBR AAC and may even release it in a matter of weeks; 192kbps is transparent for AAC and saves you at least 10% to aps (A little unscientific example; the new U2 album is 69MB with AAC@192 & 82,2MB with aps!).

That iTMS store songs only plays on the iPod is not an argument against AAC, but rather FairPlay which is the DRM system.

Just as a side-note, the Scandinavian "Sound & Vision" magazine this week had a long and detailed listening test shoot-out between the lossy formats and concluded that AAC @ 192kbps is better than mp3's at 320kbps when playing at reference systems. I'd say it's a good time to be an AAC fan these days

There must have been several bats conducting the test, that's for sure!

Actually, it was mainly the higher end tones that "did it" for mp3's disadvantage, so it could very well be bats

any links, settings and encoders used etc?

Unfortunately it's a magazine-only article in Norwegian, and at 6 pages.. I'm not sure if it'd be any point scanning it, but I could quickly translate some of the conclusions for each format. It was between mp3, atrac3plus, wma, aac and ogg at 64, 128, 192 & 320kbps.



EDIT: spelling

Difficult to compare iTunes MP3 @ 320 and Lame -aps. Too bad they didn't do a little bit of research about good MP3 encoders.

indeed.

Unsurprisingly, iTunes mp3 @ 64 was unlistenable, and 128 not recommended at all. It fared a lot better at higher bitrates and was actually better than both ogg and wma at 192kbps.. I have no idea what is better than aps and iTunes @ 320, but they were surprised at how bad it was at low bitrates compared to how well it did above 192.

Yes, it's very probable they've tested the best MP3 encoder (the most well-known) FhG at 320 Kbps, but a version which cuts-off at 16Khz or something like that...

Actually, the iTunes MP3 encoder was written from scratch, based on the ISO reference source in distribution 10, as is LAME. It was tweaked a lot earlier until focus was shifted over to the AAC encoder, but I'd be surprised if it performs worse than fhg My memory is a bit shaky, but i don't think it cut >16khz.

There is evidence that AAC decoding uses more processing power than MP3 decoding and this will affect battery drainage, though perhaps not as much as that due to the hard drive spinning up.


EDIT: grammar

I don't think THAT has been proved.. The tests that have been done have shown insignificant differences between battery life w/ mp3 vs AAC. HD spin-up and backlight are far more important.

I suggest you to search through the forums, because this was already discussed here and I think that it was QK who proved that...

OT: You are the one who is a AAC the major guardian, aren't you?

I think it is painfully obvious to anyone that CPU speed will affect battery drainage. It's a law of physics so there is nothing wrong with that statement. Also I dont see the word 'significant' in my earlier post so that's another issue, which is why I mentioned HD spin up.


EDIT: Just as a sidenote, my iPod the other day failed to change the CPU speed and ran at 80 MHz all the time. The battery level indicator dropped remarkably with an hour of playing.

yeah, well the problem is that a few more percentages in the cpu cycles doesn't necessarily impact battery life. Real life tests sure doesn't indicate it does..

yes, as you brought it up, a short summary together with codecs and settings, setup etc would be nice.

what tests?

edit: removed question

According to this article from Apple (found by Jojo in another thread), they ask you to either use a 160 kbps mp3 or 128 kbps AAC for testing your battery. Now the discrepancy in bitrates (and hence filesize) obviously means that the HD will be accessed a bit more frequently for the larger mp3 files than AAC. Wouldn't that mean your battery would be drained more for mp3s? Of course. So why suggest 160 kbps mp3 for a battery test? The simple answer is that in terms of battery usage, 160 kbps mp3 + more HD access due to larger filesize is equivalent to their standard "12 hours @ 128 kbps AAC" (for 4G iPods) figure which they keep quoting on their site.

OK, because I'm nice ;

ogg; surprisingly good at low bitrates, beats the others on 64kbps, although it has troubles with classical music especially. only beaten by aac at 128, because it for some reason messes with the stereo imaging. Same problem at 192kbps, which is why they cant recommend it at high bitrates. 6/10

mp3; terrible at everything up to 192, but it is a fairly neutral format above this. Lacks some clarity in the top, but this is more subtle at 320kbps. Sounds reasonably good at 192 and this is clearly the sweet-spot. 8-/10

wma: algorithm sounds different than aac & mp3, as this shaves more off the lower midrange. Vocals tend to get a chorus-effect at 128 something not present in the wav. Most of its issues are solved at 192 though. 6/10

aac: at 64kbps it sounds as good as mp3 at 128. At 128 the problems with the treble have been solved better than with mp3. It still lacks much of the nuances and sounds rather flat. at 192 it sounds "like a bullet". Excels in Jazz and classical compared to all others and is clearly the best all-round format.9/10

Atrac was generally quite bad, but is together with ogg the best at low bit-rates. 5/10

blind-tested at a 20.000$ reference system, and the encoders were the ones that were most popular for each format.

It was an interesting read, there's certainly not too many professional independent tests being conducted on this. Please note that I only posted the overall scores.

1. thx for the info

2. in other words: this test is totally worthless
=encoders and settings unknown. e.g., MP3 could be Blade, or LAME with a pseudo 1337 commandline etc.

the overall comments either show that the person(s?) who did the test either has very good hearing (at least considering e.g. MP3) or artifacts are easier to spot at their 10billion sytem.
if this is not the case, the comments sound a bit suspicous.

the mp3 and AAC encoders was the ones in iTunes. WMA is WMP, OGG is OGG Drop and Atrac is sonicstage. As for spotting the artifacts, that has obviously a lot to do with who listens and the hifi they used.

ah, I see.

The claim that AAC at 64 kbps sounds as good as MP3 at 128 kbps is an interesting one. I assume that it was LC-AAC, rather than HE-AAC, since it was an iTunes codec.

that is true. However, If you use --preset standard it will safe you space...the quality will be the same


Apple said that AAC drains the battery faster than mp3 @ the same bitrate. Unfortuantely, they removed that statement from their FAQ. Also, Gabriel (LAME developer) looked at the specs and also noted that AAC needs much more power. Also, I don't care about MAC-Magizines...they might be biased. I did my own tests and came to that result. I suggest you to do the same! Encode a bunch of songs you already have as mp3/AAC to mp3/AAC (same bitrate). 100 MB should be enough. Put them all in a Playlist and make sure to turn 'repeat playlist' on. Also, run the test right after your iPod has been fully charged. If you charged it the day before and it won't charge, let it play for half an hour or so and charge it again.

how do you know? Any sources? Also note, that a vbr-mode is not as easy to implement as a CBR mode and it takes a lot of tweaking. So, we'll wait and see how it's CD-Setting (if it even has one) compares to --preset standard

oops, you could get a warning for this! How do you know that? Did you try every sample? No one knows at what bitrate it is transparent. It might be transparent for you, but so is LAME 192 to some people . There was a post on this and some one mentioned that it takes 170 - 210kbps for AAC files to be transparent. So I'm not sure how you can make this clear statement. How do you know that it isn't 193kbps ot 191kbps...

what LAME version? I suggest you to try LAME 3.96.1 + --preset standard. I just tested it and it only takes up 65,68 MB See, it even safes you 4 MB and should be "more" transparent than your AAC rip

No, I base it on other people's blind-testing on this board. Several posters have come to the conclusion that 192kbps gives a level of transparancy with the QT encoder. The s&v article basically concluded with the same, so I don't think I should get a warning for my statement.



I assume this is for the Nero encoder??

on some samples it's not even transparent @ 320kbps

http://www.hydrogenaudio.org/forums/index....showtopic=28913
http://www.hydrogenaudio.org/forums/index....showtopic=24462




no, it was for iTunes/Quicktime AAC. Unfortunately, I couldn't find the thread. Maybe you are more succesfull showing me your sources
Also, I don't really care. Even if it was transparent at 192kbps, it averages at pretty much the same bitrate like LAME 3.96.1 --preset standard + gives you all the advantages of the mp3 format, such as wider software/hardware support + less battery consumption on portable devices (like on an iPod)

I'd re-read those threads if I were you, rolleyes. I'd also take into consideration that there has since been upgrades to the qt encoder. S&V used iTunes 4.7, and noted no such findings in their report.

all right, I apologize...I didn't read through the entire thread. AAC is not interesting for me. It is great on low bitrates, but when it comes to transparent sound I prefer LAME 3.96.1 --preset standard for the reasons stated above. And since iPod & Co offer so much space (increasing fast), I have no use for AAC at all...