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

[StormMeows]

StaxRip does x265 chunk encoding by cutting frames into N chunks (simple arithmetic division of the total number of frames = equal chunking) if Input/Output > Chunks is set to N in x265 Options. But unlike RipBot, each chunk employs separate processes in the SAME CPU in StaxRip.

I don't know how RipBot cuts the frames for DE in different servers, but if it cuts the frames evenly by simple arithmetic division (equal chunking), the only difference b/w StaxRip and RipBot lies in whether different CPUs can be employed (RipBot) or not (StaxRip).

And equal chunking is obviously inferior to scene-aware chunking which cuts frames based on frame similarities via ffmpeg, etc.

If you're interested in scene-aware chunking in x265, you may want to try Av1an (https://github.com/master-of-zen/Av1an). But since it's a CLI app, it has some learning curve, though.

For reference, there was a request to implement scene-aware chunking in StaxRip (https://github.com/staxrip/staxrip/issues/619), but it's put off as of now due to some difficult obstacles at the code level.

Anyway, my apologies for cluttering up this thread with StaxRip topics. :rolleyes:

Thanks for the comparison between the two programs! I really appreciate it. It sounds like for x264 8-bit 1080p blu-ray encodes, I am fine using either of these fine programs.

[Deputy Cartman]

Looooong time RipBot264 user but I'm unable to resolve an issue with Temp files and I'm hoping someone here can point me in the right direction.

I just upgraded my ancient i7-3770K desktop, using Windows 10 Enterprise, to a Ryzen 5950X so I'm interested in doing encodes on said desktop. I have had RipBot264 running on a Windows 2019 VM on my ESXi server for quite some time now, Windows Server 2016 before that, that is able to write to and use a Temp\Ripbot264temp directory hosted on a CentOS 8 VM, also on said ESXi server, no problem. I have a lot of VMs running and this 16 core Ryzen 5950X is a beast, hence my desire to shift encodes to my newly-upgraded desktop.

Unfortunately, though I've mapped the Samba share with the same CentOS 8 account credentials as on the Windows Server 2019 VM, when I try to add an encode, it always spits out:

Cannot create file
"W:\Temp\Ripbot264temp\job1\Blu-Ray_structure_getinfo.cmd". The system cannot find the file specified.

I am able to create directories and files on on the mapped network drive in Temp\RipBot264temp without incident.

I do not want to write temp files to my 2 TB NVMe SSD in order to maintain its longevity.

RipBot264.ini reads as follows when it produces the mentioned error.

StoreTempFilesin=W
*truncated*
DefaultOutputPath=W:\

Change StoreTempFilesin to C or AUTO and POOF, no more error.

I am using RipBot264 1.26.1 on both Windows Server 2019 and on Windows 10 Enterprise (21H1). I am pretty confident it has nothing to do with the CentOS 8 Samba shares because SMB3 is the minimum protocol version allowed and even the "WTF were you thinking!?" chmod 777 of the directory does not fix the issue on Windows 10 (21H1).

[guest]

Thanks for the comparison between the two programs! I really appreciate it. It sounds like for x264 8-bit 1080p blu-ray encodes, I am fine using either of these fine programs.

What you need to do is stop swapping from forum to forum, asking the same basic questions !!!

If you're after SPEED, then the ONLY option IS RipBot, and using the Distributed Encoding option, with your 5950X, it would just plough thru like nothing, as you don't use much filtering.

And if you have other PC's, they can join it, to speed it up even more !!

Until Staxrip implements a simliar DE option, (which doesn't seem to be in their plans any time soon) it WILL be slower !!!

[guest]

Hi Atak,

I can't help but hear about unprecedented rain & flooding in your part of the World....unbelievable damage.

Is this affecting you at all ??

Keep safe.

Cheers

[LigH]

In Germany, mainly the western part (Erftstadt, Wuppertal, etc.). About 160 people dead. The government was warned precisely and conveniently ahead of time; but it didn't pass through to the people. The disaster alarm system broke in the last decades. A siren test day last year failed, and this year it got postponed to next year because they did not get fixed in time.

[guest]

In Germany, mainly the western part (Erftstadt, Wuppertal, etc.). About 160 people dead. The government was warned precisely and conveniently ahead of time; but it didn't pass through to the people. The disaster alarm system broke in the last decades. A siren test day last year failed, and this year it got postponed to next year because they did not get fixed in time.

I wasn't sure what you were talking about, until I had a bit more of a look on YT, and now I know that there was some flood early warning system in place....not sure how that would be affective, a bit like forecasting earthquakes, volcanic eruptions, tsunami's, etc

It's generally too late to do much :(

[Ronski]

I do not want to write temp files to my 2 TB NVMe SSD in order to maintain its longevity.


I can't help with your network issue, but what NVME drive are you using? How many encodes do you do?

Most 2TB NVME drives have a pretty high TBW rating, so will last an extremely long time. I've recently written a huge amount of data (Chia plots) to various NVME drives, and they've all got a lot of life left. each plot creates around 1.4TB of writes. I've always used an SSD for the temp file and for storing my working files, and made use of the move setting to limit wear, but I don't do a huge amount of encodes.

[guest]

So now that I have got a 5950X, to work along side the 3950X, I have been testing these "so called" AVX & AVX2 optimized x265's...

And sadly I cannot notice a significant difference between any of them, unless I am missing something....

If anyone has an opinion on this, I would be glad to hear it.

I also ran a few tests with a 4 minute test file I have (which unfortunately only uses 3 DE servers)...

So with all the x265 builds I tried, there was only a few seconds difference in the encoding time (start to finish), which was approx 3:00 minutes (on the 5950X),
I tested on the 3950X with ALL the same settings, and it was 15 seconds quicker, due to the fact that the 3950X was to run at 100% on the 3 DE servers,
whereas the 5950X was substantially less, at around 75% +/-, due to the extra "power" the 5950X has, I guess.

And just as a reference, I also ran the 4 minute test file without DE, on the 5950X. and it took 4:11, so that's how much difference DE can make, just on the same PC.

And just as a test, I also ran it on a single E5 2690 v1, and it took 13:11, running at 100% on the 3 DE's.

So just to sum up, I was rather disappointed that the "optimized" x265's were a bit of a let down :(

[Atak_Snajpera]

Avx optimizations are always automatically used in x265 by default. To see a difference you must explicity disable them via command line.

https://x265.readthedocs.io/en/3.4/cli.html#performance-options

[Boulder]

The optimization during compiling does not help if the code is already optimized manually (i.e. written in assembly). It will help in cases where there's only pure C code or something like that.

Having said that, the GCC builds of x265 produced by the Media Autobuild Suite were a couple of % faster than any of those other available builds on my 3900X when the Zen2 optimizations were enabled. I've been using MABS to build them ever since.

[guest]

Avx optimizations are always automatically used in x265 by default. To see a difference you must explicity disable them via command line.

https://x265.readthedocs.io/en/3.4/cli.html#performance-options

Interesting...

So to lock it in, you'd use --asm avx, or --asm avx2, and to "kill" them all, it'd be --no-asm

[guest]

The optimization during compiling does not help if the code is already optimized manually (i.e. written in assembly). It will help in cases where there's only pure C code or something like that.

Having said that, the GCC builds of x265 produced by the Media Autobuild Suite were a couple of % faster than any of those other available builds on my 3900X when the Zen2 optimizations were enabled. I've been using MABS to build them ever since.

I tried a couple of DJATOM's Zen optimized builds, didn't notice any difference.

Any suggestions ??, what have you been using, and where can I get my hands on some ??? :)

I've found that 3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/

[Boulder]

I tried a couple of DJATOM's Zen optimized builds, didn't notice any difference.

Any suggestions ??, what have you been using, and where can I get my hands on some ??? :)

I've found that 3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/
This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

[guest]

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

I just tried to download this, and got this msg :(

"The file you requested has been deleted"

[Boulder]

I just tried to download this, and got this msg :(

"The file you requested has been deleted"

That service seems to allow just one download for non registered uploads.

I've put the zip file here, if it works better:
https://www.4shared.com/s/fNyWQ4RLpiq

[benwaggoner]

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.
Yeah, you want to be optimizing for YOUR version of Zen, not just Zen generically.

Profile-Guided Optimization may also help if you're trying to squeeze every last bit of performance out of it, particularly if you profile using the settings you'll be using with the final build.

[guest]

That service seems to allow just one download for non registered uploads.

I've put the zip file here, if it works better:
https://www.4shared.com/s/fNyWQ4RLpiq

Thanks for doing that, I use IDM to download stuff, and some sites don't work too well, so that's why I didn't get it on the first attempt.

Is this a "special" build ??

Cheers

[guest]

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

OK, Boulder, I have done a fair bit more testing and have some interesting results:-

Oh, and BTW, those parameters don't work under Windows, or at least in RipBot :(

So, using your x265.exe, (which seems to be 3.5+10-82786fc GCC 10.3) with my test file using --ctu 32, took 2:11, using --ctu 64, took 3:34.

The x265 I am currently using (3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/ ) using --ctu 32, took 2:07, using --ctu 64, took 3:31.

So just the tiniest bit faster....and these were ALL done at Level 5.2 10bit.

Dropping down to Level 4.0 --ctu16 (default), it took the same time, 2:07.

I read somewhere that the GCC 11.1 builds are a little better with Ryzen's.

So using --ctu 32 would yield a much faster encode, but would --ctu 64 look a little better ???? :rolleyes:

[Boulder]

I tested the two builds and the difference was just one second for 1500 frames so with my scripts and setup it's negligible. Nevertheless, the GCC builds seem best for Zen2 and probably Zen3 as well.
I use CTU 64 for 1080p and above and CTU 32 for below that.

[guest]

I tested the two builds and the difference was just one second for 1500 frames so with my scripts and setup it's negligible. Nevertheless, the GCC builds seem best for Zen2 and probably Zen3 as well.
I use CTU 64 for 1080p and above and CTU 32 for below that.

Thanks for the info, and I might do a test using 32 & 64 on a 4K encode.

Cheers

[excellentswordfight]

OK, Boulder, I have done a fair bit more testing and have some interesting results:-

Oh, and BTW, those parameters don't work under Windows, or at least in RipBot :(

So, using your x265.exe, (which seems to be 3.5+10-82786fc GCC 10.3) with my test file using --ctu 32, took 2:11, using --ctu 64, took 3:34.

The x265 I am currently using (3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/ ) using --ctu 32, took 2:07, using --ctu 64, took 3:31.

So just the tiniest bit faster....and these were ALL done at Level 5.2 10bit.

Dropping down to Level 4.0 --ctu16 (default), it took the same time, 2:07.

I read somewhere that the GCC 11.1 builds are a little better with Ryzen's.

So using --ctu 32 would yield a much faster encode, but would --ctu 64 look a little better ???? :rolleyes:
Look at your CPU utilization and you will probably find that decreasing the maximum CU size will increase the potential for higher multi threaded load. The resolution you are encoding at and the number of threads you have available will determine how much impact this will have. Also note that it might be worth changing the merange value to accommodate for this change. With a high thread CPU like 5950X you will have a hard time saturating 32 threads for 1080p and bellow for single instance encoding without lowering the CU size, hence the speed increase.

I have a vague recollection that the devs posted some tests showing that it does effect encoding output somewhat hence why they stick to 64 even for lower res (for UHD you probably always wanna stick to 64). But I'm pretty sure its rather negatable, for high core count systems its probably worth the trade off.

[guest]

Look at your CPU utilization and you will probably find that decreasing the maximum CU size will increase the potential for higher multi threaded load. The resolution you are encoding at and the number of threads you have available will determine how much impact this will have. Also note that it might be worth changing the merange value to accommodate for this change. With a high thread CPU like 5950X you will have a hard time saturating 32 threads for 1080p and bellow for single instance encoding without lowering the CU size, hence the speed increase.

I have a vague recollection that the devs posted some tests showing that it does effect encoding output somewhat hence why they stick to 64 even for lower res (for UHD you probably always wanna stick to 64). But I'm pretty sure its rather negatable, for high core count systems its probably worth the trade off.

Interesting....and it's early days for me and the 5950X, haven't really done too much with it yet, done a bit more with the 3950X, but I think the 5950X is SO much better :)

I haven't done too much in the way of "tuning" x265, and I also don't know what merange runs at, within RipBot...I thought I saw a reference, showing it @ 9, but apparently the "default" setting is 57.

https://x265.readthedocs.io/en/stable/presets.html

So some testing is on the cards, as I have a LOT to do, and a short time to do it.

[excellentswordfight]

Interesting....and it's early days for me and the 5950X, haven't really done too much with it yet, done a bit more with the 3950X, but I think the 5950X is SO much better :)

I haven't done too much in the way of "tuning" x265, and I also don't know what merange runs at, within RipBot...I thought I saw a reference, showing it @ 9, but apparently the "default" setting is 57.

https://x265.readthedocs.io/en/stable/presets.html

So some testing is on the cards, as I have a LOT to do, and a short time to do it.
"Motion search range. Default 57

The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

https://x265.readthedocs.io/en/stable/cli.html

So for 1080p and lower you might wanna try --ctu 32 --merange 26 if you use preset slow or lower, for UHD just stick with default.

[guest]

"Motion search range. Default 57

The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

https://x265.readthedocs.io/en/stable/cli.html

So for 1080p and lower you might wanna try --ctu 32 --merange 26 if you use preset slow or lower, for UHD just stick with default.

Nice, not too concerned about 1080p or lower all that much, but currently I'm doing a lot of DVD res stuff, old TV series, DVD rips etc.

But the main project is getting a LOT of 4K stuff done, it's just such a shame that it takes so long....if I could get a encode done in a day (6 - 8 hours, won't let it run overnight !!!!), that would be awesome.

So what would you recommend for nice 4K results & speed ??

Do you use RipBot ??

[Ripmann]

A quick and easy feature request for consideration:

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).

[guest]

A quick and easy feature request for consideration:

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).

I'm pretty sure that this same question was asked not too long ago..

That copy option is only available for certain file types, eg:- .ts, ,m2ts, etc. .mp4 & .mkv don't.

[ReinerSchweinlin]

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).
Yes, I asked that some time ago, too.

[chainring]

Snip...


So what would you recommend for nice 4K results & speed ??


Back some time ago, I had the same dilemma. I don't recall which thread it was in, but I asked benwaggoner and Blue_Misfit about resizing 4K content down to 2560 x X since the majority of 4K releases had been rendered at DCI 2K. I figured 2560 was a happy medium between 4K (3840) and DCI 2K (2048). Consensus was it'd be a good idea as long as my playback device could handle the resolution.

All the content I have is played back through Nvidia Shields and I have zero problems. I also play those same movies on a Samsung Tab S6 (OLED screen) via Kodi and it has no problems, either.

Anything 4K with HDR, gets the following treatment:
Resized to 2560 x X
x265 10 bit
--hdr10 --hdr10-opt
Preset Medium

Flavor to taste with:
I start with CQ16 and adjust upwards if file size gets out of control.
Denoise with MDegrain and adjust to grain content. Most of the time, MDegrain2 is the highest I go.

I've been overall very satisfied with the speed of processing when using RipBot's DE mode and four older Dell PCs. If there's no MDegrain involved, I can rip through an encode in 2-3 hours. Add in MDegrain2 and we're talking more like 9 hours. File sizes are sometimes ridiculously small, even at CQ16 and it's a bit difficult to accept, but I go with it.

[Boulder]

--hdr10-opt is the one that causes the bitrate drop, the CRF values with and without it are not directly comparable. For HDR, I use CRF 14 or 15, downscaling to 1440p or 1080p largely depending on whether it's a native 4K source or just upscaled from 2K.

[Atak_Snajpera]

You are wasting energy! 30Mbps for 1080p and 60Mbps for 2160p? That's Probably more than original bitrate. Just remux that movie and do not reencode!

[guest]

You are wasting energy! 30Mbps for 1080p and 60Mbps for 2160p? That's Probably more than original bitrate. Just remux that movie and do not reencode!

I was actually expecting you to chime in...

I think you'll find that GOOD quality original 1080p's & 2160p's can be ≥ than the bitrates I encode @ !!!

As far as I have noticed, it doesn't affect the processing time of the encode, it's simply the muxing that might take a little longer, but if you've got powerful CPU's & fast NVMe's, it's NOT an issue.

And just so you know, there's NO wasted energy here, "sunshine", I ONLY encode when I'm getting "free" power from my solar panels !!!!

Admittedly, some could be simply remuxed, but some need filtering !!

And while I have your attention, I have noticed an issue with Windows 11 (not that you'll care too much), but in the Encoding Client window, that little row of "button's" for each server, seem to loose their functionality, mainly the Shutdown Server button, not only doesn't it change it's appearance, you can't tell whether it's enabled or disabled, but either way, as it doesn't seem to want to turn off the server(s)....however, the main Shutdown Servers & Client works, tho.

[Atak_Snajpera]

You do not have my attention sunshine.

[guest]

You do not have my attention sunshine.

I beg to differ...you replied :rolleyes:

[chainring]

Hey chainring, yeah, not interested in downsizing 4K footage, I mean, that's why I bought a 4K, HDR TV !!!
4K, meh. HDR is where it's at.

I also use SMDegrain filters, found them better than MDegrain, I also don't use any CRF settings, I just go for bitrate, size is NOT an issue.
After years of messing with different scripts put together by the honest to god geniuses of Doom9, I no longer have the time nor inclination to constantly tweak scripts anymore. MDegrain works plenty good for me.

Bitrate is for when you need a predictable sized outcome. Why, if you're doing this for your own purposes, are you not letting CQ decide? Constant Quality. It ain't dumb. Go back and find posts from akupenguin and Dark_Shikari; get some history under your belt.

So 15,000kbps for 720p, 30,000kbps for 1080p, and 60,000kbps for 4K, and SMDegrain to "flavour"
You're wasting time and energy encoding at those bit rates. Why don't you stick with a remux?

[Ryushin]

Hi Atak,

I think I uncovered a bug. For some reason I can never bind to my subnet, 192.168.9.* for the encoding server. I tried adding to the encoding server:
/IP 192.168.9.40
And it always grabs the secondary IP 192.168.1.40. I added 172.28.27.40 and 192.168.0.40 as secondary IPs and the encoding server will bind to those, but not to 192.168.9.40. Very odd.

[LigH]

Shh, calm down please. Let's focus on technical solutions, not personal opinions.

[ReinerSchweinlin]

I just wanted to say "thanx" for the compare function in the avisynth tab :) Very helpful !

[slalom]

So 15,000kbps for 720p, 30,000kbps for 1080p, and 60,000kbps for 4K, and SMDegrain to "flavour"
1/2 το 1/3 of those numbers are good for me

[Daringbaaz]

Is There any Update Related to Ripbot,

Specially EncodingServer.exe

it Won't Opening on My RDP (Dedicated)

[Atak_Snajpera]

Is There any Update Related to Ripbot,

Specially EncodingServer.exe

it Won't Opening on My RDP (Dedicated)

https://forum.doom9.org/showthread.php?p=1941815#post1941815

[ReinerSchweinlin]

Hi Atak,

I think I uncovered a bug. For some reason I can never bind to my subnet, 192.168.9.* for the encoding server. I tried adding to the encoding server:
/IP 192.168.9.40
And it always grabs the secondary IP 192.168.1.40. I added 172.28.27.40 and 192.168.0.40 as secondary IPs and the encoding server will bind to those, but not to 192.168.9.40. Very odd.
Did you give "changing the network adapter priority" a try?
https://www.windowscentral.com/how-change-priority-order-network-adapters-windows-10

[Daringbaaz]

https://forum.doom9.org/showthread.php?p=1941815#post1941815

I had tried older Version 1.19.3

1st thing : My Server is EPYC and There is Not any GPU and Not any Graphics Driver Installed :)

2nd : I Try to Run Main Ripbotexe and it's Showing Warning That Java Is Not Installed, (But I Had Installed Java, Reboot Server,. But No Luck)

When i opened Encoding Server then it worked on older version,

and last thing I tried to Completely cleaned and Re-install OS (Win Server 2019)

But still Same as I mentioned)

Latest Version Showing Decoding error, after Video import and Encoding Server not Working)

in Older version : Encoding Server Worked But Main Server isn't Working :(

Please Sir, Do Something, if You Need any Donation/Contribution Then I will as much I Can.

Also If you are Available to Develop Ripbot With Some More Audio Formats then it Will Be Better .

https://i.imgur.com/gW87c7w.jpg

[guest]

For several months now, I have made available very up to date & modified build's of RipBot264.

I have also provided updates on a regular basic.

With many different extra filters & options, that made RB that little bit better than the "vanilla" version, which hasn't seen a substantial update in a very long time.

If anyone is keeping track of available updates of the components that RB use's, you'd soon realise just how far behind it is :(

I guess I was also hoping that this might prompt Atak to follow suite, and provide updates, and extra's, but it hasn't had that affect, sadly.

Don't get me wrong, RB IS still working well, but maybe Atak is now just "resting on his laurel's", and leaving good enough alone.

I also hoped that anyone that was happy to download and use my builds would also be happy to provide some feedback, either good or bad, and even the odd thanks, would have been appreciated,
but after 100's of downloads over the period I have been providing these builds & updates, not a single comment...NOTHING !!!, which sadden's me.

So as of date of posting this, I will no longer provide this service, and I will keep all my hard work to myself, and for my benefit only.

So to the many that did download my "stuff", thankyou, but you've only got yourselves to blame for this to be ending, today !!!

[darkio]

please add the ability to use external LUT 3D (.cube).
Very usefull for some old content like anime.

[Ripmann]

So as of date of posting this, I will no longer provide this service, and I will keep all my hard work to myself, and for my benefit only.

So to the many that did download my "stuff", thankyou, but you've only got yourselves to blame for this to be ending, today !!!
Hey man, you shouldn't take these things so personally. Take me for example. I asked to take a look at your SMDegrain setup, what, a month ago? And that's only because I encountered a bug and didn't have enough free time to get it working myself. I think I downloaded your file but didn't even get a chance to open the archive—let alone install or test it—with me just coming out of the hospital a few days ago and all. Not all of us got sick, of course, but I'm sure other people also have unrelated things on their mind, especially considering the s%*storm the world is currently in. And even for those who don't, with dozens, if not hundreds of programs installed on an average computer, I'd speculate that you're not the only not getting any feedback on your efforts. Doesn't mean that they are not appreciated. Hell, I've been using RipBot for a decade and only bothered commenting on it last year or so. For the average user, "if it works, it works" is the standard operating mantra.

TL;DR version: take it easy, and on behalf of everyone who asked to use your stuff, thank you.

•

P.S. I don't know about "resting on his laurels" (which frankly no longer sounds as comfortable as it did back in Ancient Greece) but I'd also really welcome more development pouring into RipBot. Although I'm still a devout user, it's getting harder and harder to stay with it without being forced to use other tools—tools I previously didn't even like. E-AC3, up-to-date HDR/HDR10+/DV tools and support, and perhaps a more comprehensive set of degrain filters like SMDegrain (or whatever better alternatives are out there) would really be appreciated. I know it's a lot to ask from a selfless developer who already sacrificed so much of his time into this free software, but that's what you get when you end up with thousands of people depending on your work. Perhaps, if you feel exhausted, you can reconsider going the open source route? I'm sure someone will be willing to pick up the burden like they did with MPC and MPC-HC/MPC-BE. Wouldn't make your own legacy any less meaningful. Quite the opposite, in fact.

[guest]

Hey man, you shouldn't take these things so personally. Take me for example. I asked to take a look at your SMDegrain setup, what, a month ago? And that's only because I encountered a bug and didn't have enough free time to get it working myself. I think I downloaded your file but didn't even get a chance to open the archive—let alone install or test it—with me just coming out of the hospital a few days ago and all. Not all of us got sick, of course, but I'm sure other people also have unrelated things on their mind, especially considering the s%*storm the world is currently in. And even for those who don't, with dozens, if not hundreds of programs installed on an average computer, I'd speculate that you're not the only not getting any feedback on your efforts. Doesn't mean that they are not appreciated. Hell, I've been using RipBot for a decade and only bothered commenting on it last year or so. For the average user, "if it works, it works" is the standard operating mantra.

TL;DR version: take it easy, and on behalf of everyone who asked to use your stuff, thank you.

•

P.S. I don't know about "resting on his laurels" (which frankly no longer sounds as comfortable as it did back in Ancient Greece) but I'd also really welcome more development pouring into RipBot. Although I'm still a devout user, it's getting harder and harder to stay with it without being forced to use other tools—tools I previously didn't even like. E-AC3, up-to-date HDR/HDR10+/DV tools and support, and perhaps a more comprehensive set of degrain filters like SMDegrain (or whatever better alternatives are out there) would really be appreciated. I know it's a lot to ask from a selfless developer who already sacrificed so much of his time into this free software, but that's what you get when you end up with thousands of people depending on your work. Perhaps, if you feel exhausted, you can reconsider going the open source route? I'm sure someone will be willing to pick up the burden like they did with MPC and MPC-HC/MPC-BE. Wouldn't make your own legacy any less meaningful. Quite the opposite, in fact.

Thanks, Ripmann,

Good to hear you're OK, now..sure a crazy time, atm. :(

I actually only got asked by about 3 ppl, and with the 100's of downloads, you'd think that at least 1 or 2 would bother to leave a comment, (good or bad).

I know that E-AC3 conversion has been asked about for age's, but is just brushed aside, but there are other app's that do the job very & quickly, and all you have to do is mux it in either before or after a RB encode.

I generally do video ONLY for 4K stuff, as I need to convert the TrueHD track & subtitles tracks to be compatible with my equipment.

Also have started splitting 4K movies into 20 - 30 minute chunks, then importing them in using the Batch feature, that way you don't have to hope your PC (or RB) will reliably encode for a day or so.

A little bit more procedure, but a lot less anxiety, I can tell ya !!

I'm sure that HDR could be updated fairly easily, there's always someone out there working on that side of things.

Anyway, life goes on.

Stay well, my friend.

[guest]

please add the ability to use external LUT 3D (.cube).
Very usefull for some old content like anime.

Has this got anything to with Adobe files ?? (.cube)

[darkio]

Has this got anything to with Adobe files ?? (.cube)

yes, but there are free luts can be used.
Da vinci resolve use luts and many others.
It's color correction (color grading).
Sometime, source video have bad colours can be improved.
Avisynth use luts too for editing.

[guest]

yes, but there are free luts can be used.
Da vinci resolve use luts and many others.
It's color correction (color grading).
Sometime, source video have bad colours can be improved.
Avisynth use luts too for editing.

So why can't you process the files you want, THEN run them thru RipBot if needed.

I doubt that your request will be addressed.

[darkio]

So why can't you process the files you want, THEN run them thru RipBot if needed.

I doubt that your request will be addressed.

because there are 2 time compresion.
ripbot can handle simple color correction like satutation, contrast etc,
so, why can't use external lut?