I'm trying to squeeze the best possible quality out of a 128kbps mp3
so far i've been using "-V 5 -h" with Lame 3.96.1
i wasn't sure about the -h, should i use it? and is there anything else i should add?
These will be streaming off a webserver, that's why i need them to be 128kbps (or close to that since i prefer VBR)
For ~ 128kbps VBR, the general consensus has been to use "-V5 --athaa-sensitivity 1" with LAME 3.95.1 or higher. The ATH adjustment was found to result in less warbling/phasing, but may raise the bitrate a little bit.
The -h is redundant and therefore not needed.
thanks
the reason i was worrying about using "-h" which is the same as -q2, cause without it, the encoder uses -q3 instead
so are you saying theres no difference between the two?
So "-V5 --athaa-sensitivity 1" is better than "--preset 128 --athaa-sensitivity 1"?
I don't know it at all. I would use "-V5 --athaa-sensitivity 1" but I don't know.
/edit: So at those bitrates is it better to use VBR instead ABR? I just don't know.
thanks
the reason i was worrying about using "-h" which is the same as -q2, cause without it, the encoder uses -q3 instead
so are you saying theres no difference between the two?
[a href="index.php?act=findpost&pid=265601"][{POST_SNAPBACK}][/a]
From about 3.94 or 3.95 onward, the default "high-quality" setting is -q3, not -q2. As far as I know, there is not yet been any evidence to show that lower -q values bring higher quality, so just stick with the default. -q0-q2 also take longer to encode, which isn't worth it considering the aformentioned lack of evidence.
So "-V5 --athaa-sensitivity 1" is better than "--preset 128 --athaa-sensitivity 1"?
I don't know it at all. I would use "-V5 --athaa-sensitivity 1" but I don't know.
/edit: So at those bitrates is it better to use VBR instead ABR? I just don't know.
[a href="index.php?act=findpost&pid=265607"][{POST_SNAPBACK}][/a]
personally, I think that there is no need for CBR/ABR anymore because of the VBR presets aka -V2 etc. Anyway, -V5 should be better...
thanks for the help
but i was also wondering...does the prefrence of "--athaa-sensitivity 1" apply to all bitrates or just a certain range?
Hello
I just finished encoding about 150 songs with the "-V5 --athaa-sensitivity 1"
(3.96.1 ) setting. I'm happy. I found this preferable to "--alt-preset 128" (3.90.3) for my needs. I also noticed that when I tried "-V4 --athaa-sensitivity 1" that the file sizes jumped up quite a bit. I too am not sure when the "--athaa-sensitivity 1" should be used
There is a thread discussing some of the tests recently done with VBR and lower bit rate encoding. I would suggest reading it as well.
Regards
Randy
the reason i was worrying about using "-h" which is the same as -q2, cause without it, the encoder uses -q3 instead
[a href="index.php?act=findpost&pid=265601"][{POST_SNAPBACK}][/a]
AFAIK q2 from 3.90.3 = q3 from 3.96.1. Just a shift in numbers.
thanks for the help
but i was also wondering...does the prefrence of "--athaa-sensitivity 1" apply to all bitrates or just a certain range?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=265668")
You don't need to use it at -V4 or higher quality levels. Look [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=21012&view=findpost&p=205737]here[/url] for the explanation by Gabriel. You can also read that entire thread if you want more information on how we got to this.
And for the people that didn't know this already: "-V5 --athaa-sensitivity 1" was also used for Roberto's latest 128kbps test, and it performed quite well (roughly on par with iTunes AAC):
http://www.rjamorim.com/test/multiformat128/results.html (http://www.rjamorim.com/test/multiformat128/results.html)
offtopic from my original post....but is 89db the best setting for mp3gain?
cause everything sounds really quiet
edit: nm answered my own question by searching around
personally, I think that there is no need for CBR/ABR anymore because of the VBR presets aka -V2 etc. Anyway, -V5 should be better...
Though for lower bitrates there still seems to be some issues with VBR:
http://www.hydrogenaudio.org/forums/index....ndpost&p=264990 (http://www.hydrogenaudio.org/forums/index.php?showtopic=30547&view=findpost&p=264990)
...i was also wondering...does the prefrence of "--athaa-sensitivity 1" apply to all bitrates or just a certain range?
Good question... Anybody have an answer?
>>personally, I think that there is no need for CBR/ABR
??
Are you kidding ?
Think of streaming...
...i was also wondering...does the prefrence of "--athaa-sensitivity 1" apply to all bitrates or just a certain range?
Good question... Anybody have an answer?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=266601")
that has been already answered in this thread (just a few posts above yours)...
You don't need to use it at -V4 or higher quality levels. Look [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=21012&view=findpost&p=205737]here[/url] for the explanation by Gabriel. You can also read that entire thread if you want more information on how we got to this.
And for the people that didn't know this already: "-V5 --athaa-sensitivity 1" was also used for Roberto's latest 128kbps test, and it performed quite well (roughly on par with iTunes AAC):
http://www.rjamorim.com/test/multiformat128/results.html (http://www.rjamorim.com/test/multiformat128/results.html)
[a href="index.php?act=findpost&pid=265745"][{POST_SNAPBACK}][/a]
>>personally, I think that there is no need for CBR/ABR
??
Are you kidding ?
Think of streaming...
[a href="index.php?act=findpost&pid=266623"][{POST_SNAPBACK}][/a]
who uses mp3 for streaming? And what's wrong with a vbr stream?
>>who uses mp3 for streaming?
Everybody.
Almost
You can stream not only a music, video+sound too.
>>And what's wrong with a vbr stream?
??
The main problem is that it's vbr...
that has been already answered in this thread (just a few posts above yours)...
D'OH!
Thanks, Jojo...
My apologies for the redundancy...
I use mp3 for streaming. What is the problem with that???
It suits all my needs plus works flawlessly (unlike other streams I tested)...
VBR streaming works ok for me...
EDIT: typo
>>What is the problem with that???
With fixed channel width, if bitrate exceeds it you will have a glitch...
>>What is the problem with that???
With fixed channel width, if bitrate exceeds it you will have a glitch...
[a href="index.php?act=findpost&pid=266635"][{POST_SNAPBACK}][/a]
Of course this totally depends on the underlying protocol. Most audio streaming now is done via TCP, which handles the flow control so VBR is not a problem. Of course TCP is not the ideal multimedia protocol, but that doesn't stop people from using it (its easy to use and is network-friendly).
also, talking about 'glitches' in mp3 streams...at what bitrate are those streams usually done? I mean, even if that happens it's not that some one listens to some 320kbps stream...I'd say streams mostly use 128kbps or less...however, I can't think of any web radio or something that streams in mp3...and as freakngoat said, there's a work around to that...
Overall, I think that just a vbr mode in LAME would have many more advantages than disadvantages...
also, talking about 'glitches' in mp3 streams...at what bitrate are those streams usually done? I mean, even if that happens it's not that some one listens to some 320kbps stream...I'd say streams mostly use 128kbps or less...however, I can't think of any web radio or something that streams in mp3...and as freakngoat said, there's a work around to that...
Overall, I think that just a vbr mode in LAME would have many more advantages than disadvantages...
[a href="index.php?act=findpost&pid=266643"][{POST_SNAPBACK}][/a]
Yes most streaming is done at lower bitrates for obvious reasons. VBR creates a variety of problems. One of the problems with using VBR in multimedia streaming is that if you are not using any flow control mechanism, and your bitrate suddenly jumps up above your maximum bandwidth, those frames will be lost (this has a profound effect in MPEG video streaming, since the most likely frame to be dropped is the I-frame, and thus all the frames received up until the next I-frame will be junk). Other problems arise when using a packet resend strategy (like TCP). Peaks and valleys in birates are not network friendly with multiple receivers, since more packets are likely to be dropped at a peak, and so more people will request a resend at once, choking off bandwidth for everyone. Luckily TCP has a congestion avoidance scheme as well, otherwise a "broadcast storm" can occur, where everyone is requesting a resend, but nobody backs off. If this occurs effective playback becomes impossible.
What it comes down to is, VBR creates non-network friendly traffic with multiple receivers.
EDIT: BTW there are lots of radio stations streaming in MP3. Also in my previous post, I should have said VBR is "possible," as I've just described the problems associated with it.
does these VBR drawbacks occur only with mp3 VBR or with other VBR streamable codecs (ogg, aac etc. etc.)?
anyway. i stream mp3 vbr from my home pc to my work pc and never heard any glitch... perhaps I'm just lucky.
>>perhaps I'm just lucky
Sure, wide channel, one transmitter - one receiver: no problems most of the time...
I think, freakngoat described the problem with vbr very well:
What it comes down to is, VBR creates non-network friendly traffic with multiple receivers.
It couldn't be done better with one sentence
EDIT:
does these VBR drawbacks occur only with mp3 VBR or with other VBR streamable codecs
That's the nature of vbr, not the codec...
does these VBR drawbacks occur only with mp3 VBR or with other VBR streamable codecs (ogg, aac etc. etc.)?
anyway. i stream mp3 vbr from my home pc to my work pc and never heard any glitch... perhaps I'm just lucky.
[a href="index.php?act=findpost&pid=266672"][{POST_SNAPBACK}][/a]
These drawbacks are with any VBR codec. Its the shape of the traffic thats the problem, not the data.
Yes, VBR is great for just streaming from one computer to another, and TCP works fine for this (with sufficient buffering). As long as your buffer is big enough and you have sufficient bandwidth, your playback will be resistant to network latency and jitter, as well as congestion. Since streaming music is non-time critical (unlike video conferencing or VoIP), having a big buffer is fine.
Its not ideal when VBR is used on top of a protocol such as TCP to send to multiple clients, which is most commonly done in internet radio stations.
Lots of research has gone into the area of multicast multimedia streaming. There are better protocols for specifically designed for streaming multimedia, but as we know, better technology is often discarded in favor for the old ways that still seem to work okay. This is why TCP is used.
Lots of research has gone into the area of multicast multimedia streaming. There are better protocols for specifically designed for streaming multimedia, but as we know, better technology is often discarded in favor for the old ways that still seem to work okay. This is why TCP is used.
I may be wrong here but here it goes:
I am sure that there are specific protocols for streaming that are better than TCP/IP, but it sounds naive to me to think that they would be favoured instead of a widely accepted/tested/deployed standard as TCP/IP...
If the underlying internet infrastructure needs to be changed (TCP/IP included) then it just won't happen. It's a huge investment for little perceived gain IMO of course...
Again I may be totally wrong...
sorry for drifting offtopic...
I am sure that there are specific protocols for streaming that are better than TCP/IP, but it sounds naive to me to think that they would be favoured instead of a widely accepted/tested/deployed standard as TCP/IP...
If the underlying internet infrastructure needs to be changed (TCP/IP included) then it just won't happen. It's a huge investment for little perceived gain IMO of course...
[a href="index.php?act=findpost&pid=266719"][{POST_SNAPBACK}][/a]
Nothing would have to change on the underlying internet infrastructure; multicast is built-in to the IP specification (though routers must support IGMP). The only change would be at the application layer. Protocols such as RTP (Real Time Protocol) run on top of UDP, coexisting peacefully with TCP.
Some of these protocols are already being used for video conferencing and VoIP.
I see... sorry for my noobness...
Just curious, what are the usual file sizes for 128kbps VBR MP3 files?
Similar to the filesizes obtained by 128 CBR mp3s. Around 1MB per minute of material.
Just curious, what are the usual file sizes for 128kbps VBR MP3 files?
[a href="index.php?act=findpost&pid=266780"][{POST_SNAPBACK}][/a]
well, if it is 128kbps it's 128kbps...it doesn't matter if CBR or VBR . By the way 128kbps means 16KB per second...
I think, freakngoat described the problem with vbr very well:
What it comes down to is, VBR creates non-network friendly traffic with multiple receivers.
It couldn't be done better with one sentence
[a href="index.php?act=findpost&pid=266678"][{POST_SNAPBACK}][/a]
isn't that why most media player use a buffer? I never had any problems listening to VBR files on the web...
isn't that why most media player use a buffer?
[a href="index.php?act=findpost&pid=266939"][{POST_SNAPBACK}][/a]
They use a buffer because the connection speed is unreliable, there are dropouts related to line noise, ISP load, local PC load, etc.
All codecs made for streaming (Real, Windows Media, MP3) are CBR, or have a CBR mode.
The problem with VBR is that you can't say "
this stream is for people on 128kbps ISDN,
this stream is for people on dial up,
this stream is for people on T1..." because the peaks in bitrate usage lead to stutter. Just look at Shoutcast, they could be easily using VBR encoding, since the Shoutcast DNAS uses Lame, but with VBR they wouldn't be able to explain what are the bandwidth requirements for each station.
The problem with VBR is that you can't say "this stream is for people on 128kbps ISDN, this stream is for people on dial up, this stream is for people on T1..." because the peaks in bitrate usage lead to stutter. Just look at Shoutcast, they could be easily using VBR encoding, since the Shoutcast DNAS uses Lame, but with VBR they wouldn't be able to explain what are the bandwidth requirements for each station.
[a href="index.php?act=findpost&pid=266943"][{POST_SNAPBACK}][/a]
Yes. And when traffic is correlated (meaning the shape of the traffic is the same for many connections), average throughput goes way down. This is because when packets are dropped at certain peaks, they will be dropped for many receivers at once, overwhelming the sender that has to resend those packets (leading to dropouts for everyone). With a CBR mode, dropped packets will occur randomly for each receiver, and average throughput for everyone increases. A graph would show this quite nicely.
Normal internet traffic has peaks and valleys, but its not a problem because they happen at random times, so average throughput is maximimized. Traffic correlation is why routers use an algorithm called Random Early Detection (RED), which starts dropping packets randomly as a router's buffer fills up, as opposed to a drop-tail algorithm, which drops everything once the buffer is full. RED helps to decorrelate the traffic.
isn't that why most media player use a buffer? I never had any problems listening to VBR files on the web...
They use a buffer mostly to avoid dropouts due to latency and jitter issues. However, you are correct in assuming that using a buffer will let you get away with receiving bitrates which are higher than your maximum bandwidth temporarily. For example, if you were playing an MP3 encoded using VBR, and your incoming bandwidth was limited to 256kbps, even though there are 320kbps frames, as long as the average bitrate of the music was kept under 256kbps (the average bitrate MUST return to less than 256kbps before the buffer is exhausted), then you'd be okay and not experience any dropout. Obviously the bigger the buffer, the longer the music could temporarily go above the maximum bandwidth allowed. Again in the case of one receiver, VBR works fine and would be prefered.
All codecs made for streaming (Real, Windows Media, MP3) are CBR, or have a CBR mode.
A codec could also use ABR if it actively enforces some buffer verifications, in the same way as the "cbr" mode of AAC.