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

[00-00]

Originally Posted by rlev11

Just out of curiosity, I would mux out the audio file from the original using mkvtoolnix which will save it as a .mka file. Then add that newly created file to the outputted file that ran through ripbot. I would be curious to see how the audio syncs up doing it that way. So essentially using the video part from ripbot, and the audio part from the original.

Well that was strange - it worked! I tried extracting the audio separately and remuxing it afterwards previously with no luck, but doing it this way worked! I've never tried doing it this way before though, through mkvtoolnix, as I usually use tsmuxer if I have to demux a track.

So thank you for that, much appreciated!

[stryker412]

What is everyone's personal CRF preference for 1080p?

[LigH]

I wish this question would mean anything so I could answer...

[microchip8]

Originally Posted by stryker412

What is everyone's personal CRF preference for 1080p?

x264: CRF 21

x265-10bit SDR: CRF 23
x265-10bit HDR: CRF 18

[stryker412]

Originally Posted by microchip8

x264: CRF 21

x265-10bit SDR: CRF 23
x265-10bit HDR: CRF 18

Not an argument, just curious. Why 23 vs the default of 20?

[microchip8]

Originally Posted by stryker412

Not an argument, just curious. Why 23 vs the default of 20?

20 was chosen at the beginning, when they added presets, and hasn't changed. At that time, x265 wasn't very good still so it needed more bitrate. Now, x265 is "good enough(tm)" and 23 is optimal CRF for me wrt quality/file size trade-off

[LigH]

There may be different factors to select your preferred CRF.

But the video resolution should hardly be one.

[stryker412]

Originally Posted by microchip8

20 was chosen at the beginning, when they added presets, and hasn't changed. At that time, x265 wasn't very good still so it needed more bitrate. Now, x265 is "good enough(tm)" and 23 is optimal CRF for me wrt quality/file size trade-off

Gotcha, thank you.

[Boulder]

Originally Posted by LigH

There may be different factors to select your preferred CRF.

But the video resolution should hardly be one.

With bigger resolutions, you might get away with a slightly higher CRF as the possible artifacts are often not as visible (because they are enlarged less if at all).

When talking about CRF, it must be remembered that the "hdr10-opt" parameter that should be enabled with HDR encodes, shifts the scale a bit so you can use a 1-2 points lower value for the same average bitrate.

[rlev11]

Originally Posted by Boulder

With bigger resolutions, you might get away with a slightly higher CRF as the possible artifacts are often not as visible (because they are enlarged less if at all).

When talking about CRF, it must be remembered that the "hdr10-opt" parameter that should be enabled with HDR encodes, shifts the scale a bit so you can use a 1-2 points lower value for the same average bitrate.

So what exactly does having the --hdr10-opt (or even the --hdr10) in the x265 command line do. I have been running for the longest time with just the default ma10 profile in ripbot that just has
--profile main10 --output-depth 10
in it. It appears to me when encoding hdr, that even with the default setting, that the bt2020 parameters for hdr are being passed in the encode.

[Boulder]

Originally Posted by rlev11

So what exactly does having the --hdr10-opt (or even the --hdr10) in the x265 command line do. I have been running for the longest time with just the default ma10 profile in ripbot that just has
--profile main10 --output-depth 10
in it. It appears to me when encoding hdr, that even with the default setting, that the bt2020 parameters for hdr are being passed in the encode.

--hdr10-opt will offset QPs based on the luma level of the frame so it will allocate bits better considering the characteristics of HDR sources being different from SDR ones.

You can use MediaInfo to see which parameters have been used on the video.

[valnar]

Hey everyone. My Google Fu is failing me.

Is there a tutorial on Batch mode? My episode files have a DTS-HD track and I assumed with the defaults based on this pic, it would copy the stream over. Instead it's converting it to FLAC. How can I adjust that?



In case the pic doesn't come through, it's the default batch window of

Audio 1:
DEFAULT
English
1_audio

7.1|COPY STREAM
5.1|COPY STREAM
2.0|COPY STREAM
5.1|FFMPEG AC3|640 kpbs
2.0|FFMPEG AC3|256 kbps

[slalom]

That's a lot of pages back...

try this

[activoice]

Before encoding a video I strip out any subs I don't want leaving just the English Subtitles, and English Forced Subtitles. I make sure that the forced subtitle has the Forced value set to YES

When the Forced Subtitles are de-muxed they end up in the corresponding Job folder with a file name like this (so far so good)

1_subtitles_English_DEFAULT_FORCED.srt

But after encoding has been completed by Ripbot and the output is remuxed that subtitle still ends up with the Forced value set to NO, I need to open the output file in MKVToolnix change the flag to Yes and Remux it.

When I look at Profile setting under preferred forced subtitles, it says FORCED and has examples of English|Forced.SSA as the filename to be used.

But I don't control the filename that the subtitle is output as. Does that mean I should be entering this file name in that field for it to retain the forced flag?

1_subtitles_English_DEFAULT_FORCED.srt in that box?

Or if that's not it, how do I retain the Forced value without having to remux after the encode?

[Atak_Snajpera]

Is 1_subtitles_English_DEFAULT_FORCED.srt automatically selected in SUBTITLES section after demuxing?
I think the problem is that 1_subtitles_English_DEFAULT_FORCED.srt was originally muxed with two flags DEFAULT and FORCED. In that case RipBot treats that file as DEFAULT.

[activoice]

Originally Posted by Atak_Snajpera

Is 1_subtitles_English_DEFAULT_FORCED.srt automatically selected in SUBTITLES section after demuxing?
I think the problem is that 1_subtitles_English_DEFAULT_FORCED.srt was originally muxed with two flags DEFAULT and FORCED. In that case RipBot treats that file as DEFAULT.

Usually if you have a Forced Subtitle it's also the first subtitle and is often set to Default YES and Forced YES.

I did a test just now where I set Default to NO and Forced to YES, but Ripbot still did not set it to forced automatically in the job.

I also tried adding both English_DEFAULT_FORCED and DEFAULT_FORCED to the preferred forced subtitle box and that didn't do anything either.

It seems the only workarounds are to either Edit the job to manually select the subtitle I want forced. Or to edit the output with MKVToolnix, set the flag to YES and Remux.

[hardkhora]

Has anyone been able to get RipBot to work with Linux via WINE?
I know a Virtual Machine (VM) option exists but would take more resources... and I'm trying to de-windows my life, but it is soo hard
I saw some interest from a few users (TDS, apol847, dv8r, BLKMGK, Ryushin, and mparade)

Or is there something for Linux that does distributed encoding like RipBot?

[Atak_Snajpera]

Originally Posted by activoice

Usually if you have a Forced Subtitle it's also the first subtitle and is often set to Default YES and Forced YES.

I did a test just now where I set Default to NO and Forced to YES, but Ripbot still did not set it to forced automatically in the job.

I also tried adding both English_DEFAULT_FORCED and DEFAULT_FORCED to the preferred forced subtitle box and that didn't do anything either.

It seems the only workarounds are to either Edit the job to manually select the subtitle I want forced. Or to edit the output with MKVToolnix, set the flag to YES and Remux.

It is a bug. I will fix that soon.

[activoice]

Originally Posted by Atak_Snajpera

It is a bug. I will fix that soon.

Thanks

[rlev11]

Originally Posted by Boulder

With bigger resolutions, you might get away with a slightly higher CRF as the possible artifacts are often not as visible (because they are enlarged less if at all).

When talking about CRF, it must be remembered that the "hdr10-opt" parameter that should be enabled with HDR encodes, shifts the scale a bit so you can use a 1-2 points lower value for the same average bitrate.

Thanks for the info on hdr10-opt especially since i always encode with a CRF of 18.
I did a couple quick tests and re-encoded some hdr material using hdr10-opt in the command (along with what I believe is correct from reading also adding --aq-mode 2).
I can not tell any visual difference in the new encodes EXCEPT I am now getting anywhere from a 5 - 40 percent decrease in the final output size. So a win-win in my book.

Since having --hdr10-opt in the profile will not ignore and blow up the encode on non-hdr material, I just now have an additional profile I use specifically for hdr material now which is no problem.

Also, I posted back a bit that I was having issues with the latest encoding client .exe. Just recently I let ripbot auto update again which installed the latest version. I have done a bunch of encodes recently and have had no issues. Not sure if something was updated with ripbot, or something maybe with a windows update took care of the issue. Just wanted to get that out there....