Hi,

Is there any way how can I encode wav files to lame mp3 format with select target file size?

for example some software where can I choose VBR, 50MB and it calculate destination bitrate?

The equation:
%bitrate% = %wished size in kilobits% / %audio length in seconds%

Follows: kb/s = kb / s

use as lame --abr %bitrate% <file>

Unfortunately, no encoding software that I know of does this. But, if you know the total track time(s) and the desired encoded size, then your desired bitrate follows of necessity. The hydrogenaudio Wiki for LAME has a table of VBR x bitrates that may be useful to you.

No it doesn't. That table is highly misleading because of its wording. VBR has no target bitrate! What the table shows is just a typical average over an entire music collection. An album encoded at V2 may come out at 150kbit, another may come out at 230kbit. VBR does not target bitrates - it targets qualities. If you want predictable filesizes, then use ABR - its meant for exactly this purpose.

However, i do agree that it would be a nice feature, if one could specify a target filesize instead of bitrate for ABR and CBR. The problem with that is that lame encodes track by track - the actual calculation for an entire album would need to be done be a frontend which knows about all the files which are to be encoded. Propose such a feature to devs of frontends, like dbpa, eac or foobar.

Setting a target file size pretty much guarantees suboptimal encoding. Either your files won't sound very good because there were too few bits, or you will be wasting space with little or no improvement in quality.

"Optimal" encoding is only possible, if the encoder has full freedom in how to spend bits - thus, if you do not put any restraints on bitrate. At the moment where you want a target filesize, you have already limited the encoder in its flexibility..... it does not matter if you do that automatically via ABR, or manually VBR.... you are limiting the bitrate by desiring a target filesize.

However, given how efficient lame is nowadays, that tradeoff can be efficient if target filesize is important. Its not like many people can recognize a 192kbps ABR track (i would like you to prove, that ABR encodings typically sound "not very good"... and i dont mean killer samples, but random music tracks). MP3 nowadays has lots of reserves... enough to sacrifice some of it for other purposes.

Lyx -



Given with moskyt's calculated bitrate and using the Wiki table for the INITIAL track VBR x, a converging algorithm would hit the desired encoded size. And, isn't the quality of VBR is superior to ABR?

Yes, because it is allowed to be unpredictable. At the moment where you want it to be predictable..... i.e. my adjusting VBR-settings to fit desired bitrate, you are taking away that advantage. Technical details aside, by adjusting VBR-settings to bitrate, you are in princible turning it into ABR. The idea behind ABR is exactly that: loosely adjusting quality to fit overall bitrate.

P.S.: Minor evil detail: It is theoretically possible, to create a more qualitative file by manually adjusting VBR, because lame has no multipass ABR encoding. When you manually adjust VBR to fit a given bitrate, you are basically doing some kind of manual multipass ABR encoding. But do you realize how annoyingly much effort that is? Is that worth it? Can you perceive it?

But, a superior ABR, no?

See my addition - yes, superior ABR qualitywise..... but regarding needed effort, quite inefficient.

This made me think of the D2SRoBa plugin that I wrote for DVD2SVCD. For video it makes a lot of sense with one-pass VBR where you can predict an exact bitrate. This plugin basically encodes e.g. 1% of the video frames througout the movie, and adjusts the quality a few (1-3) times to hit 1% of the target size. The surprising thing is that one percent of the frames (e.g encode 10 frames each 1000 frames) is usually enough to get a pretty close result (less than 2% off). The automatic analysis of the quality setting is therefore very fast.

With the new floating point -V option in lame 398b8, in theory this could be implemented for lame as well, and we could replace the current ABR (which doesn't give exact bitrate anyway). However, mp3 encoding is not equal to video encoding, and the quality vs. bitrate scale probably isn't smooth growing as it should be for this to work well.

edit: moderated a few statements.

I did think that this could also be combined with a briefly scanned spectral analysis of the audio content of the source material to determine an upper cut-off frequency which could set a low-pass filter parameter to increase potential quality for a given value of -V. Alternatively, it could back off the -V value on top of the method suggested above in relation to spectral content.

It could almost bring an end to general ABX testing for those without 'golden ears' if it can hit the right targets automatically.

Just a thought.

Cheers, Slipstreem.

Now this is starting to get interesting. However, it may make sense to first take a closer look at how lame ABR works - so, which strategy is used. Without knowing how efficient the existing implementation is, its impossible to estimate how much room there is for improvement.

Hmm, I'm kind of finding this topic interesting, too.

Say, I wanted a file that was 50MB. So I calculate out the bitrate and encode it ABR.

Now say that I also encode the source file with VBR 10 different times, once at V0, once at V1, once at V2... all the way to V9. Of the ten different files I have, one of these files will likely be close to 50MB (Though it's not guaranteed.) If one does appear, should this file have better quality than the ABR one, theoretically? And if so, can't a program do this, in a 2-pass type method so that the file does not need all the different encodes?

That's precisely what tycho and I are proposing. You could determine a target filesize for VBR with possible quality improvement via intelligent low-pass filtering. Just feed the source material to an intelligent front-end which could then select an appropriate -V value and possible supplementary low-pass filtering, and a file pops out the other end of approximately the right size.

I'm seriously hoping that someone can start development work on this idea ASAP. I don't have the necessary software writing skills myself but am certainly happy to invest my time with as much ABX testing as needs to be done to get it working satisfactorily.

Cheers, Slipstreem.

It's quite obvious that a VBR encoding with e.g. bitrate 140 may have significantly better quality than an ABR encoding at the same bitrate. Especially if the VBR one uses a large bitrate span throughout the encoding. The reason is simply that ABR combines two constraints: quality and bitrate, whereas VBR only has one constraint: quality.

/add: in other words, ABR tries to keep constant quality, but adaptively adjusts the quality setting to adhere to the bitrate constraint, which will lead to lower quality at certain points in the encoding compared to the VBR one.

It's hard to understrand, really. I feel you are right, but no rational prove here - ABR IS VBR already; Size constraints are equal for both (equal bitrate). Whats a difference?

Edit: I've reread wiki. So, it is different "aggression" algorithms.

In reply to the post above...

I've made the following graphs to clearly show the difference in bitrate distribution used across the frames when encoding the same track using VBR versus ABR. Both files have an average bitrate of 140Kbps.



The track encoded was Equinoxe Part 5 from the Jean-Michel Jarre album Equinoxe. It may not be representative of a typical encoding, but the spectral content and wide dynamic range of this particular recording shows how well LAME VBR can adjust to fulfill the requirements of complex source material. It also shows the distinct lack of flexibility offered by ABR when using the same encoder.

In this particular case, the two encodings are so easily distinguishable for me that an ABX test seemed like a total waste of time. I can tell one from the other within a few seconds of the track starting. The VBR encoding preserves most of the original crispness, rapidity of attack and dynamicism of the percussive sounds and the ABR encoding sounds as though it's had the life sucked out of it.

Cheers, Slipstreem.

Let me explain why I asked a question "how can I make mp3 with target size option"

I my country (czech) some people makes hdtv rips from original (english) hdtv video and czech audio (VBR!!) from tv... resulting avi files have 350MB size (e.g. 315MB video and 35MB audio).


For example it is made with this procedure:
1) demux original english hdtv rip --> result is hdtv rip without audio (315MB) - (X)
2) encoding czech audio --> result is mp3 lame VBR with some bitrate - (Y)
3) combine X+Y = (Z)

And final hdtv rip (Z) is original hdtv video and czech mp3 audio (VBR) with size 350MB... I find that original hdtv video is untouched so the only one way is make mp3 with exact size (350MB-315MB=35MB)...

So I am looking for some process how can I makes hdtv rips from untouched hdtv video and audio in VBR with exact avi file size.

For videos and streaming, especially when the videocontainer is AVI, plain old ABR is usually the most meaningful option (for such scenarios, you actually WANT a small averaging window size - and thats what lame ABR does).

So the answer to your problem is:

A) encode to ABR, everything works right and you dont need to worry about how to do it.

B) encode to VBR a dozen times manually until the bitrate matches, you may run into sync issues and you will pull your hair off how to keep the required effort down.

Strange this thread for a question that was solved in the second post already by mdefranc. ABR is the way to go for optimal quality within a preset file size. You can also go CBR, but then you are not optimizing encoding quality within the preset file size.

ABR is not VBR, is it? AFAIR VBR is more flexible.

Nero AAC-Encoder, 2-pass option. Of course this could be done with mp3 if it was implemented. Make a first (or even more) pass to get an approximation and a last pass to finally encode. Honestly, I wouldn't need it, but hey, "impossible is nothing".

Probably you could also batch it if the lame cli would offer something like a bitrate return value after encoding.

ABR and VBR are two different encoding strategies, but both produce VBR files.

Hence the graphs I showed earlier in post#18. I hoped it might make the ABR vs VBR situation a little clearer to those still struggling to get to grips with it.

Cheers, Slipstreem.

the missing feature in this conversation is 2pass encoding.

if/when lame has this feature, then most ideas discussed in this topic are achievable - but at this time it isn't realistic.


later

Try reading back to post#11.

Cheers, Slipstreem.

This is a front-end feature, but I don't know about any front-end allowing this.

Over the past years, this was discussed a few times here. I think that it would be possible with a front-end encoding some chunks of the audio file through a few -Vx settings, and then do the whole encoding. (as already mentioned within this thread)