My files sizes are +-10MB with the newest beta using x265 and 3 pass encoding

[VEGAX265]

In Staxrip 2.1.8.5 beta
I created a new profile using the x265 encoder.
I set my x265 to run three passes. I don't change any of the other settings for the encoder.
Selective SAO: used to be set to 4 now I just leave it at default.
I set my file size to 372 for the size the calculated Video Bitrate: says 551.
The file processes and outputs a file 361MB in size.

Why are my files off by up to 10MB different than the 372 input for the size in this new beta?

Staxrip 2.1.8.4 beta had the following 372 for the size the calculated Video Bitrate: says 578.
None of the output files ever matched this calculated Video Bitrate box but the files were always 372MB +-1MB.

Right clicking on Video Bitrate: gives me "Target Video Bitrate in Kbps (Up/Down key)"
So what is this box really showing me compared to the final output file?
2.1.8.5 output video bit rate is 983kb/s with overall is 1195kb/s
2.1.8.4 output video bit rate is1014kb/s with overall is 1227kb/s

Also is there any way to use Staxrip to do multi pass using the x265 quality setting?

test_X265_VEGA_staxrip 2.1.8.5 beta.log

srip profiles.zip

mediainfo.txt

[stax76]

There might be an issue with a recent change.

[Dendraspis]

I set my file size to 372 for the size the calculated Video Bitrate: says 551.
The file processes and outputs a file 361MB in size.

Why are my files off by up to 10MB different than the 372 input for the size in this new beta?

Staxrip 2.1.8.4 beta had the following 372 for the size the calculated Video Bitrate: says 578.
None of the output files ever matched this calculated Video Bitrate box but the files were always 372MB +-1MB.

Can you give us the correct sizes in BYTES instead of MB?

Starting with v2.1.8.5 StaxRip uses the SI prefix according to IEC (see Changelog). So MB instead of MiB, which was used but with the wrong prefix.
1 MB = 1,000,000 Bytes
1 MiB = 1,048,576 Bytes
100 MiB = 104,86 MB

Windows is still using the wrong prefix. 👎

Btw: Same with x265 by Patman, which also uses MB instead of MiB for the file sizes since v3.5RC1+29.

[VEGAX265]

This is the file size I got according to media info File size: 362 MiB total file and Stream size: 297 MiB (82%).
According to windows its Size is 361 MB (379,113,184 bytes) and its Size on disc is: 361 MB (379,113,472 bytes)

I wanted File size media info File size : 372 MiB this is from an older encode using old profile
Approximately Windows its Size is 371 MB (389,583,591 bytes) and its Size on disc is: 371 MB (389,586,944 bytes)

I entered 372 in Staxrip , What should be entering?
Using the math above I should be seeing a file closer to 379MiB not smaller
also is 100 MiB = 104,86 MB 100 MiB = 104.86 MB comma vs period?

Please let me know Thanks

[Dendraspis]

Ok, I had to check it (again), but everything works as intended.

Filesize: 200 (entered)
Bitrate: 6986 (calculated)
Audio: 500 (total of 2x 250kbps audio tracks

The source file has 5342 frames @ 25 fps, so we estimate:
6986 kbps + 500 kbps = 7486 kbps in total
7486 kbps / 8 / 25 fps = 37.43 KB per frame
37.43 KB * 5342 = 199,951.06 KB = 199.95106 MB = 190.68819 MiB

The resulting file is about 1.84 MB or 1.72 MiB smaller:

So there are your "10MB":
372 MiB = 390,070,272 B = 390 MB
372 MB = 372,000,000 B = 354.77 MiB

So in order to achieve 372 MiB, you must enter 390 MB:
372 MiB * 1024 * 1024 / 1000 / 1000 = 390 MB
Or short:
372 MiB * 1.024² = 390 MB

The difficulty is, that Windows and some old apps still use MiB, but show MB as unit, which is wrong.
I think I'm going to implement a switch to let the user decide which unit should be used. 🤔 When you only work with Windows tools and binary prefix, it might be a bit annoying.

BTW:
This is the reason why you buy a 10 TB harddisk drive and when you install it Windows tells you it has only "9.095 TB" to use - because it's not 9.095 TB but 9.095 TiB whereas the HDD has real 10 TB.

[ghost]

The MiB vs MB has been introduced for maybe 20 years (or more) now, and still there is always a confusion about it... I don't know how this has to be adressed...

[Dendraspis]

I think it's because Windows displays MB and nobody pays attention if there is an i in between, because it's too small/thin.

[VEGAX265]

Just a thought.
The simple way to do this is to include defaults under the Size: menu options to put "X" number of files per DVD-R or BD-R minus about 5MiB for extras like covers pics.

Would it be possible to get the units on the screen next to the boxes?

[Dendraspis]

@VEGAX265
You can add some custom sizes to the Targetsize menu by yourself. 😉

Here is the last build with optional prefix, can be set via Settings:
StaxRip v2.1.8.5D_Prefix.zip

Please note, that the Targetsize menu must be resetted or adjusted by hand after a change!

[VEGAX265]

Thank you for the math help today. Im fighting a sinus infection and my head was really hurting from this.
I use the Size: label all the time, love it too. I just have to re enter my files sizes every time there is a new build with drastic changes. not a big deal as I only really use 5 different file sizes. 5,10,20,22,24 per DVD-R
When i right click the box there is no info box like there is for the Video Bitrate:

Very nice StaxRip v2.1.8.5D_Prefix.zip Can you put the selected prefix on the user interface next to the box?

I do most of my files in batch mode. Is there any way to make Staxrip do x265 constant quality with a multi pass?

[ghost]

Is there any way to make Staxrip do x265 constant quality with a multi pass?

No there is no such option, because multi-pass modes are already constant quality modes.
Think of it like that (although this is not totally accurate, but t helps understand): the analysis passes allow to analyze the full video and establish a complexity chart of the frames, then with the specified global bit rate, a global constant quality factor is calculated. When the last pass runs, it encodes with this global constant quality factor.
REMEMBER this is not totally accurate, but helps understand 😁

[VEGAX265]

Thanks for quick explanation 44vince44.
If you do get the prefix on the main interface screen a right click info for "Total Output File Size" would be nice to explain the difference in bytes as Dendraspis stated.
1 MB = 1,000,000 Bytes
1 MiB = 1,048,576 Bytes

Thanks for clearing my head up today. This is closed with me
Keep up the great work.

[Dendraspis]

a right click info for "Total Output File Size" would be nice to explain the difference in bytes as Dendraspis stated.

Is already explained via HelpText of the setting and the Changelog. 😁

Can you put the selected prefix on the user interface next to the box?

I think so. 😁
Here is the latest build:
StaxRip v2.1.8.5D_Prefix2.zip

[VEGAX265]

awesome sauce you rock!

[VEGAX265]

I tested the exe files that were sent over to me and they changes were great showing us what units are used.
Im still having issues with the file sizes not being right in the end. I went back to 2.1.8.4 beta and the problem is there as well.
I think it has to do with the audio file changing size and the bitrate not compensating like it used to. All 3 passes are using the same original bitrates. After it finishes converting the audio file there is a line in all of my logs that shows Video Bitrate: 702 -> 691 with similar numbers depending on the length of the video.

It looks like 2.1.8.5 is always taking the number on the left of that Video bitrate line.
For this one my audio file was smaller after conversion and it said this Video Bitrate: 910 -> 937 but all three passes used the 910 bit rate.

Also at that point I dont know if the number generated after audio conversion is in KiB or KB per seconds
I can post logs if you like.

[ghost]

post the log please i'll take a look... and tell me when was the exe sent to you.
Can you also tell me:
-what was the size requested
-did you select in settings MiB

[Dendraspis]

Maybe this has something to do with the latest issue regarding the prefix and overhead calculation in #597.

Please take the zip file from my latest posts, should be Prefix6. This one was tested, compared to manual calculations and it works.

[VEGAX265]

will do as soon as I can

[VEGAX265]

i was running on StaxRip v2.1.8.5D_Prefix2.zip from the link above.

Where \ how do I get Prefix6?

StaxRip v2.1.8.5D_Prefix2 in MiB mode
2021-03-14 - 15.48.35 - file01_358MiB_staxrip.log

StaxRip v2.1.8.4 Beta
2021-03-19 - 14.34.10 - file02_372MiB_staxrip.log

Im betting that #597 has this fixxed.

After reading #597 the Video Bitrate Box in Staxrip v2.1.8.5 is always kbps no mater what mode Mib or MB?

[ghost]

Yes we worked on it yesterday and fixed it,
The kbps is always kbps because this is how all encoders work. They expect kbps.
Get Prefix6 hotfix here: #597 (comment)

I think that you have to set your preferences to MiB, and remember that what Windows OS displays as "MB" are in reality MiB.

@VEGAX265
Also remember that the audio encoder sets an ESTIMATE of the resulting kbps, which will be more accurate if you set the number of channels. Example, if you are using AAC:

• if you leave the number of channels to "Original" it will show 290kbps, even if the source file is 2 channels! 290 is of course unrealistic.
• if you set number of channels =2, then the estimate becomes 96kbps, which is more realistic.

But if you are not re-encoding audio, then it uses the exact kbps of the existing audio.

[VEGAX265]

Tested last night using the exe from StaxRip.v2.1.8.5D_Prefix6.zip in both modes MiB and MB. Both are not moving the second calculated video bitrate from qaac audio encoder over to the 3rd and second passes.
this is found under audio
-------------------------- Audio Encoding 1 --------------------------
qaac 2.71
Video Bitrate: 473 -> 457 and Video Bitrate: 927 -> 959 respectively

I went back and checked my logs it was working properly in StaxRip.v2.1.8.2 and failed in StaxRip.v2.1.8.3

[VEGAX265]

537MiB actual output 523MiB.log

213MB actual output (218,479,405 bytes) 208MiB.log

[ghost]

@VEGAX265 in order to understand what is happening, I need a screenshot of the main window to see what values are displayed before processing. If you still have the temp files, you can still open the .srip file in staxrip and drop a screenshot here...

Also I don't understand what you mean by this:

Video Bitrate: 473 -> 457 and Video Bitrate: 927 -> 959 respectively

and this:

Both are not moving the second calculated video bitrate from qaac audio encoder over to the 3rd and second passes.

Please explain.

[ghost]

@VEGAX265 You are expecting that the video bitrate gets adjusted in Nth pass / 2nd pass when the audio has been encoded and its bitrate is accurately known ?

Please try to explain clearly before I answer you...

[VEGAX265]

Sorry for the delay the computer that encodes is at work and I have to remote into it to get my screen shots.

I just saw that StaxRip-v2.1.9.0-Beta-x64.7z was released and I am reading thru the change log.
This may have been fixed in this release.

You are expecting that the video bitrate gets adjusted when the audio has been encoded and its bitrate is accurately known ?

Please try to explain clearly before I answer you...

Yes exactly
It is showing the adjustment in the audio section but it never gets applied in any of the video passes.

[ghost]

@VEGAX265 now we understand what you mean! We're investigating...

[ghost]

This seems like something that has been dropped long ago, Dendraspis is still investigating...

[VEGAX265]

Hope you find it I have around 80 videos 50+ hours I have to redo. lol
It seemed to be working in StaxRip.v2.1.8.2 beta
Thank you guys

[ghost]

We finally understood, you know, neither Dendraspis and I use multi-pass encode, so we didn't really see this feature/issue...

[Dendraspis]

It seems my recent fix fixed an old bug, but created a new one. I will fix it for sure, but it might take a bit.

Hope you find it I have around 80 videos 50+ hours I have to redo. lol

Ouch.

neither of Dendraspis and I use multi-pass encode, so we didn't really see this feature/issue...

Multi-pass with audio, that's the point. 🤓

[Dendraspis]

Little update:
Fortunately I did not create a new bug. 😁 This bug was "introduced" in v2.1.8.2, so the latest working version with this feature is v2.1.8.1.

Will take a bit to find a solution...

[Dendraspis]

More than complex, took me more time than I thought. But it should be fixed now:
StaxRip v2.1.11D.zip

[JJKylee]

Off topic:
So the next beta version is 2.1.11? You decided not to attach the last 0 in the build number? 🙄

[Dendraspis]

@JJKylee
Saw your post on Doom9 and wanted to write you when I stop wrestling with myself. 😉
But have a look at this: #579 (comment)

[JJKylee]

I already did and left a reply.
I like the new naming scheme better. At least users won't get confused. 😃

[ghost]

@Dendraspis please begin new naming from v2.2 🙏🏼
if you begin now people are gonna get confused !!

[Dendraspis]

Stop being off-topic and tell me if the fix works for you, too. 😄 😜

[JJKylee]

To be frank, I dare not do a 3-pass encoding with x265. 😝
I'll pass the honor over to @44vince44, or @VEGAX265. 😁

[ghost]

OK I'll check now with latest exe I have.. just give me the time to do the encode... (using 4K upscaling and setting x265 on placebo, and using a sample file of 4 hours). And using a 2 core processor. It's a pity Staxrip does not work on 32 bit OS otherwise I'd do the test on a 32 bit OS.

[ghost]

Last hotfix has successfully fixed the problem! well done @Dendraspis !! 🎉 🚀