Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: --preset standard aka -V2 --vbr-new (Read 3766 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

--preset standard aka -V2 --vbr-new

Hey,

I encode some stuff with the 3.97a10, which works quite well. I use -V2 --vbr-new.

What I see is, theres often many samples (>80%) encoded in 192k, 10% in 160 and 10% 224.

I know it depends on the source material, but this is pretty obvious. In other versions (or was it in vbr old) there was a wider spreading of the bitrates, which, I may be wrong, to me feels like being more realistic, adaptive and better.

Someone else recognized this?

--preset standard aka -V2 --vbr-new

Reply #2 –
i remember hearing this mentioned briefly in another thread a while ago.  it might have been the official 3.97a10 release thread, or maybe one of the other many threads asking about it.  but i believe gabriel may even have mentioned it, or at least been present in the general discussion, but no specific reason was given for the less spread distribution of frame bitrates.  i too am curious about this apparent contradiction, but i guess as long as the quality turns out as good, it doesn't matter how they do it.  the things those dev's can do never ceases to amaze me.

edit: iirc, all --vbr-new files had this tendency, to be less distributed
a windows-free, linux user since 1/31/06.

--preset standard aka -V2 --vbr-new

Reply #3 –
In this thread, timcupery appears to have experienced a narrower bitrate spread with --vbr-new as well.

Regards,
Madrigal

--preset standard aka -V2 --vbr-new

Reply #4 –
Thanks Madrigal, I was just wondering if I'd have to build a link to that previous thread. Not that the issue ever got resolved. I still have semi-distrust of --vbr-new because it seems that effective VBR would be spreading the frame sizes around more depending on complexity of each frame being encoded. However, I can't argue with testing showing that --vbr-new (in 3.97a10) is outperforming the old vbr algorithm...
God kills a kitten every time you encode with CBR 320

--preset standard aka -V2 --vbr-new

Reply #5 –
Quote
Thanks Madrigal, I was just wondering if I'd have to build a link to that previous thread. Not that the issue ever got resolved. I still have semi-distrust of --vbr-new because it seems that effective VBR would be spreading the frame sizes around more depending on complexity of each frame being encoded. However, I can't argue with testing showing that --vbr-new (in 3.97a10) is outperforming the old vbr algorithm...
[a href="index.php?act=findpost&pid=309382"][{POST_SNAPBACK}][/a]

I think the bitrate spread may be related to a difference in how vbr-new uses the bitreservior compaired to vbr-old rather than the actual bits its giving each frame.
Its just a possibility, just noting that indicated framesize includes bitreservoir allocation so if eg vbrnew was using the reservoir more than old, it would allow the apparent framesize to be more restricted. 'So many variables - thats why the tests are the ultimate indicator.
no conscience > no custom