RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY

[Atak_Snajpera]

Profiles/Audio.txt

Originally Posted by Atak_Snajpera

Profiles/Audio.txt

Audio.txt

2.0 OPUS CODEC      64 kbps [abr]
2.0 OPUS CODEC      96 kbps [abr]
2.0 OPUS CODEC     128 kbps [abr]
5.1 OPUS CODEC     160 kbps [abr]
5.1 OPUS CODEC     240 kbps [abr]
5.1 OPUS CODEC     320 kbps [abr]
7.1 OPUS CODEC     224 kbps [abr]
7.1 OPUS CODEC     336 kbps [abr]
7.1 OPUS CODEC     448 kbps [abr]
2.0 FHG AAC-HE      64 kbps [abr]
2.0 FHG AAC-LC      96 kbps [abr]
2.0 FHG AAC-LC     128 kbps [abr]
2.0 FHG AAC-LC     256 kbps [abr]
5.1 FHG AAC-HE     192 kbps [abr]
5.1 FHG AAC-LC     256 kbps [abr]
5.1 FHG AAC-LC     320 kbps [abr]
7.1 FFMPEG AAC     384 kbps [abr]
7.1 FFMPEG AAC     448 kbps [abr]
7.1 FFMPEG AAC     640 kbps [abr]
2.0 FFMPEG AC3     192 kbps [cbr]
2.0 FFMPEG AC3     224 kbps [cbr]
2.0 FFMPEG AC3     256 kbps [cbr]
5.1 FFMPEG AC3     384 kbps [cbr]
5.1 FFMPEG AC3     448 kbps [cbr]
5.1 FFMPEG AC3     640 kbps [cbr]
2.0 FFMPEG FLAC    ??? kbps [vbr]
5.1 FFMPEG FLAC    ??? kbps [vbr]
7.1 FFMPEG FLAC    ??? kbps [vbr]

Well, I know my crystal ball doesn't work, are you trying to suggest that it can be simply added to this list ??

UPDATE:- I thought I'd try this, and it indeed add's it to the Profile options for the job, I guess the proof is in the pudding if it actually encodes it to that setting.

[Juha]

I tested editing that text file. I managed to convert with that custom value. Thanks!

Another question if you don't mind...

I wonder what would be sane values when denoising a specific grainy video?

Sample pics:
Original video: https://images2.imgbox.com/0d/ce/X8DX3n8B_o.png
Used Degrain3, 400 : https://images2.imgbox.com/91/c9/EUoz0E3G_o.png
Used Degrain3, 800 : https://images2.imgbox.com/08/e5/yKAB34TV_o.png

Sample pics2:
Original video: https://images2.imgbox.com/d5/50/loTDbpNr_o.png
Used Degrain3, 400 : https://images2.imgbox.com/79/78/Pec7u2cb_o.png
Used Degrain3, 800 : https://images2.imgbox.com/4d/6d/FlrBBok1_o.png

What I'm asking is second a second opinion - do you think those values are reasonable / do those pictures look good? Personally I think both of them look good to me. I'm just worried that Degrain3 800 would be too much.

Originally Posted by Juha

I tested editing that text file. I managed to convert with that custom value. Thanks!

Good to know that you sorted the audio situation

SMDegrain would probably do better (but that's a whole different story)..

It doesn't really matter what other ppl might say..if it looks good to you, that's all that matters.

TBH, your source file is pretty bad, what resolution is that ??

[rlev11]

Originally Posted by Juha

I tested editing that text file. I managed to convert with that custom value. Thanks!

Another question if you don't mind...

I wonder what would be sane values when denoising a specific grainy video?

Sample pics:
Original video: https://images2.imgbox.com/0d/ce/X8DX3n8B_o.png
Used Degrain3, 400 : https://images2.imgbox.com/91/c9/EUoz0E3G_o.png
Used Degrain3, 800 : https://images2.imgbox.com/08/e5/yKAB34TV_o.png

Sample pics2:
Original video: https://images2.imgbox.com/d5/50/loTDbpNr_o.png
Used Degrain3, 400 : https://images2.imgbox.com/79/78/Pec7u2cb_o.png
Used Degrain3, 800 : https://images2.imgbox.com/4d/6d/FlrBBok1_o.png

What I'm asking is second a second opinion - do you think those values are reasonable / do those pictures look good? Personally I think both of them look good to me. I'm just worried that Degrain3 800 would be too much.

I don't think that I have ever used anything more than Mdegrain3-400 on even my most grainy sources. I use smdegrain now but even with that I would use something equivalent in degraining strength.

There is a point in my eyes where too much degraining can cause adverse picture quality. Where I would notice it in particular would be peoples foreheads when there is motion. I would notice the pores get washed out really bad and get "plastic" looking. then when stopped the pores would return.

I also hate film grain so there is a fine balance between too little and too much degraining.

I'm pretty much to the point now where I only use 3 different strengths. Very little grain , some grain , a lot of grain. I watch a couple scenes of a video and just pick the one I feel is the closest and go with it. You will never completely eliminate a heavy grained source and retain all the detail. Even something like Topaz AI is going to struggle with that.

[Juha]

Originally Posted by FTLOY

TBH, your source file is pretty bad, what resolution is that ??

Believe it or not, but it's an uncompressed Full HD H264 video from a Blu-Ray disc... It's a 90's movie.

Originally Posted by rlev11

I don't think that I have ever used anything more than Mdegrain3-400 on even my most grainy sources. I use smdegrain now but even with that I would use something equivalent in degraining strength.

There is a point in my eyes where too much degraining can cause adverse picture quality. Where I would notice it in particular would be peoples foreheads when there is motion. I would notice the pores get washed out really bad and get "plastic" looking. then when stopped the pores would return.

I also hate film grain so there is a fine balance between too little and too much degraining.

I'm pretty much to the point now where I only use 3 different strengths. Very little grain , some grain , a lot of grain. I watch a couple scenes of a video and just pick the one I feel is the closest and go with it. You will never completely eliminate a heavy grained source and retain all the detail. Even something like Topaz AI is going to struggle with that.

After giving some thought to this I think I'll use 800 in my case. The difference between 400 and 800 looks quite marginal and I feel that even stronger degraining could be used but I guess it's better not to overdo it. This looks good to me.

Thanks for replies.

I just wanted to post something about this again, as it will need to be addressed sometime soon.

For the users that like to update RB manually, any recent x265 builds, will produce an error like this :-

""\\RYZEN-9-7950X\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\RYZEN-9-7950X\RipBot264temp\job3\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\RYZEN-9-7950X\Ripbot264temp\tools\x265\x265_x64.exe" --seek 0 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --crf 16 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 3610 --sar 1:1 --level 5.2 --profile main10 
--output-depth 10 --ctu 64 --high-tier --vbv-bufsize 240000 --vbv-maxrate 240000 --y4m --pools "32" --output "\\RYZEN-9-7950X\RipBot264temp\job3\Chunks\1.265" -"

x265 [WARN]: extra unused command arguments given <->

[Juha]

I ripped my first 4K movie. For testing purposes, I made two rips of it:

- 4K resolution rip
- Full HD resolution rip (resized original 4K to Full HD)

I used the setting to crop black bars but Ripbot only cropped black bars from 4K rip. 4K -> Full HD rip didn't get black bars cropped.

I suspect it's because I didn't choose "custom" as the output resolution, but if I crop something, shouldn't it always be taken into account even if I choose a predefined resize option?

4K rip: https://images2.imgbox.com/07/ad/hd6GSBcs_o.png

Full HD rip: https://images2.imgbox.com/b9/ca/j4n4wjg7_o.png

(Screenshots were taken by using MPC's native "save image" function.)

Cropping / resize settings in Ripbot I used for the Full HD rip: https://images2.imgbox.com/da/a4/vBf2sUmF_o.png

Resolution of the output 4K rip is 3840 x 1600. Full HD rip is 1920 x 1080.

Originally Posted by Juha

I ripped my first 4K movie. For testing purposes, I made two rips of it:

- 4K resolution rip
- Full HD resolution rip (resized original 4K to Full HD)

I used the setting to crop black bars but Ripbot only cropped black bars from 4K rip. 4K -> Full HD rip didn't get black bars cropped.

I suspect it's because I didn't choose "custom" as the output resolution, but if I crop something, shouldn't it always be taken into account even if I choose a predefined resize option?

4K rip: https://images2.imgbox.com/07/ad/hd6GSBcs_o.png

Full HD rip: https://images2.imgbox.com/b9/ca/j4n4wjg7_o.png

(Screenshots were taken by using MPC's native "save image" function.)

Cropping / resize settings in Ripbot I used for the Full HD rip: https://images2.imgbox.com/da/a4/vBf2sUmF_o.png

Resolution of the output 4K rip is 3840 x 1600. Full HD rip is 1920 x 1080.

Have you tested them on your TV ??

[Juha]

No issues when viewing on TV. Just that they (black bars) are unnecessary and waste of bitrate / encoding time. Not necessarily much but still.

[rlev11]

Originally Posted by Juha

I ripped my first 4K movie. For testing purposes, I made two rips of it:

- 4K resolution rip
- Full HD resolution rip (resized original 4K to Full HD)

I used the setting to crop black bars but Ripbot only cropped black bars from 4K rip. 4K -> Full HD rip didn't get black bars cropped.

I suspect it's because I didn't choose "custom" as the output resolution, but if I crop something, shouldn't it always be taken into account even if I choose a predefined resize option?

4K rip: https://images2.imgbox.com/07/ad/hd6GSBcs_o.png

Full HD rip: https://images2.imgbox.com/b9/ca/j4n4wjg7_o.png

(Screenshots were taken by using MPC's native "save image" function.)

Cropping / resize settings in Ripbot I used for the Full HD rip: https://images2.imgbox.com/da/a4/vBf2sUmF_o.png

Resolution of the output 4K rip is 3840 x 1600. Full HD rip is 1920 x 1080.

What you want to do when downsizing like what you are doing is after you do the autocrop, in your case will show 280 pixels for top and bottom. When you do the resize, choose the second to the bottom, which will be custom (and the aspect ratio) in your case Custom [2.40:1]. Then in the width section, change 3840 to 1920. Height will automatically change to 800 then in your case.

This way you will get what you are trying to do is downsize the encode without encoding the black bars. Doing the 1920x1080 [2.40:1] will encode it at the resolution specified which would be 1920x1080, but will just put the flag into the stream that it is a 2.4:1 aspect ratio.

This way only works if the aspect ratio is one of the presets built into ripbot. I think what is in now is 1.78,1.85,2.0,2.35, and 2.4.

If the pixels are just a few off just choose the preset that it shows, So if the autocrop shows 2.394:1 just choose the 2.40 and go. you will not notice those couple of pixels added or missing.

If it is not really close to one of the presets for something oddball, just get out the calculator and figure out what the 1920 x height number is (round up or down if not a full pixel) by using the SAR number from the autocrop if you have black bars on top and bottom. Vertical bars you would do the same except take 1080 times the SAR number. So a SAR of 1.5 would be 1620x1080.

This is where you would use the bottom custom resize setting that lets you choose both width and height. Bottom line is for horizontal bars use 1920 as the width and calculate the height, and for vertical bars use a height of 1080 and calculate the width.

Originally Posted by Juha

No issues when viewing on TV. Just that they (black bars) are unnecessary and waste of bitrate / encoding time. Not necessarily much but still.

So if it plays OK on your TV, and if you've got a reasonably powerful CPU, then why bother....I rarely crop.

And after rlev11's excellent explanation, it might take you longer to "set it up" than how much longer those black bars take to process, and from what I understand, if you don't get it right, then you'll have to do it all over again....just sayin'.

Originally Posted by rlev11

what you want to do when downsizing like what you are doing is after you do the autocrop, in your case will show 280 pixels for top and bottom. When you do the resize, choose the second to the bottom, which will be custom (and the aspect ratio) in your case custom [2.40:1]. Then in the width section, change 3840 to 1920. Height will automatically change to 800 then in your case.

This way you will get what you are trying to do is downsize the encode without encoding the black bars. Doing the 1920x1080 [2.40:1] will encode it at the resolution specified which would be 1920x1080, but will just put the flag into the stream that it is a 2.4:1 aspect ratio.

This way only works if the aspect ratio is one of the presets built into ripbot. I think what is in now is 1.78,1.85,2.0,2.35, and 2.4.

If the pixels are just a few off just choose the preset that it shows, so if the autocrop shows 2.394:1 just choose the 2.40 and go. You will not notice those couple of pixels added or missing.

If it is not really close to one of the presets for something oddball, just get out the calculator and figure out what the 1920 x height number is (round up or down if not a full pixel) by using the sar number from the autocrop if you have black bars on top and bottom. Vertical bars you would do the same except take 1080 times the sar number. So a sar of 1.5 would be 1620x1080.

This is where you would use the bottom custom resize setting that lets you choose both width and height. Bottom line is for horizontal bars use 1920 as the width and calculate the height, and for vertical bars use a height of 1080 and calculate the width.

wow !!!

[Atak_Snajpera]

Originally Posted by FTLOY

So if it plays OK on your TV, and if you've got a reasonably powerful CPU, then why bother....I rarely crop.

And after rlev11's excellent explanation, it might take you longer to "set it up" than how much longer those black bars take to process, and from what I understand, if you don't get it right, then you'll have to do it all over again....just sayin'.

Are you sure about that?

1920x1080 + MDegrain2 400


1920x800 + MDegrain2 400


You basically get ~16% faster script processing for free. Add x265 encoder and it may go up to ~20% total.
Here We call this optimization...

Originally Posted by Atak_Snajpera

Here We call this optimization...

Ha, not everything needs to be cropped, and some it's a little complicated.

Autocrop can sometimes not do the job properly, and I'm not going to get the calculator out.

If it looks OK on the TV, WGAF !!, I did a crop test a week or so ago, and it looked the same....

[Atak_Snajpera]

Originally Posted by FTLOY

Ha, not everything needs to be cropped, and some it's a little complicated.

Autocrop can sometimes not do the job properly, and I'm not going to get the calculator out.

If it looks OK on the TV, WGAF !!, I did a crop test a week or so ago, and it looked the same....

You still do not understand why we crop... I'm out.

Originally Posted by Atak_Snajpera

You still do not understand why we crop... I'm out.

Well, you're not good at explaining anything, we all seem to need a crystal ball, you just expect us to know..

I'd like to say more, but I don't want to get banned.....

[Boulder]

There's no reason not to crop. The borders are not always totally black and also may contain (invisible) compression artifacts which affect the bitrate needed.

Cropping has been a strong recommendation since I started working with video stuff over 20 years ago.

Originally Posted by Boulder

There's no reason not to crop. The borders are not always totally black and also may contain (invisible) compression artifacts which affect the bitrate needed.

Cropping has been a strong recommendation since I started working with video stuff over 20 years ago.

I have never cropped, unless it's a strange ratio to start with, or old 4:3 stuff.

And I've been encoding for 20+ years too....

[rlev11]

Going back to my test video of ST Strange new worlds in 4k. Original pixels is 3840x2160, but in a 2.4:1 aspect ratio so there are 560 horizontal lines of black space. If I encode it without an autocrop (x265 and using Smdegrain...), my test chunk on my 7950x shows 14.06 fps. That same chunk with an autocrop so encoding 3840x1600 comes out at 19.83 fps. That like a 29% increase in speed at the expense of 2 extra clicks. Resizing that down to 1080p takes 3 more clicks and typing in 1920. And "getting the calculator out" would be very rare if only downsizing an oddball aspect ratio.
To each his own, but I will keep cropping useless data and enjoy the speed increase for the time of a few extra clicks....