View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
Atak_Snajpera
25th October 2021, 22:00
Uninstall GeForce experience.
guest
26th October 2021, 01:25
No change from above, if EncodingServer.exe tries to run then RipBot will hang. The machine is dual boot and the same problem whether I run on Win 11 current version or latest insider release (dev channel). RipBot, Windows and all other software are latest versions, as is motherboard bios (Gigabyte Aorus B550 Pro V2)
Avisynth+ is 3.7.0 and the Nvidia software is
Release Version
FrameView SDK 1.1.4923.29968894
GeForce Experience 3.23.0.74
Graphics Driver 472.12
PhysX System Software 9.21.0713
Windows Insider Dev Channel
FrameView SDK 1.1.4923.29968894
GeForce Experience 3.23.0.74
Graphics Driver 510.31
PhysX System Software 9.19.0218
Hopefully you will have a better result.
Yes, there it is, and like Atak said (above post).
RipBot has a long history with certain elements of nVidia drivers, so you really only need to do a "Custom" install, and then probably only choosing the main graphics driver, maybe the audio driver, and maybe Physics, but NOTHING else, and DON'T use the "Express" install option !!!
You can go one step further if you like and grab this :-
https://www.techpowerup.com/download/techpowerup-nvcleanstall/
or
https://www.nvidia.com/en-us/drivers/driver-utility/
And customise your "bloated" nVidia driver package to install only what you really need.
Good luck, I might even do the same myself.
Cheers
archiel
26th October 2021, 12:41
Uninstall GeForce experience.
Done ....and all is fine again. Thank you
archiel
26th October 2021, 12:41
Yes, there it is, and like Atak said (above post).
RipBot has a long history with certain elements of nVidia drivers, so you really only need to do a "Custom" install, and then probably only choosing the main graphics driver, maybe the audio driver, and maybe Physics, but NOTHING else, and DON'T use the "Express" install option !!!
You can go one step further if you like and grab this :-
https://www.techpowerup.com/download/techpowerup-nvcleanstall/
or
https://www.nvidia.com/en-us/drivers/driver-utility/
And customise your "bloated" nVidia driver package to install only what you really need.
Good luck, I might even do the same myself.
Cheers
Thanks for the links, I will have a play later.
chainring
29th October 2021, 18:00
Speaking of video drivers...
In the past, I've had some occasional server stalls when doing encodes in DE mode with MDegrain active. The freeze would manifest itself with one, or multiple, servers stalling during the encode process. Kill the server, restart and the encode continues.
I'm using four Dell PCs, all with built-in Intel graphics. Intel has had a problem with a process called Desktop Window Manager going crazy and, if memory serves, gobbling up RAM. Beta graphics drivers from Intel fixed the DWM thing and it seems that may have also fixed the stalled server problem, too. I've processed at least ten 4K HDR movies, using MDegrain, and so far not one stall.
Noisrevid
4th November 2021, 14:49
I'm trying to figure out for the life of me why Handbrake is encoding about 8x-10x faster with the exact same x265 settings and presets on both GUIs.. Tried multiple machines and they all are acting the same way. Example, Faster preset for HEVC in Ripbot264 = like 12 fps.. Handbrake = 100+ fps. Tried GPU decoding and CPU decoding in settings for Ripbot264 and doesn't make much if any difference on any Nvidia or AMD machine. Tried Intel and AMD CPU powered machines, same issue. Couldn't find anything in the forum giving me any indication why Ripbot264 would be up to 10x slower..
Edit: Resolution was set to 720p in both Ripbot264 and Handbrake from original 1080p (same clip used). Confirmed all threads are being used by Ripbot264 as well and "Use Multiple processing threads" is checked.
Edit 2: New observation is that smaller videos seem to encode at roughly the same speed in Ripbot264 but longer videos just encode incredibly slow right away. Both original videos are the same exact format as each other, one's 15 minutes, one's 1.5 hours.
SKPN
4th November 2021, 14:51
I've been having some issues recently with encodes hanging after completing the chunks. I use the batch encoder distributed among two servers (one on the main encoding PC and the other in a VM on my gaming PC). Sometimes the encodes will go through from start to finish and work properly, but other times the chunks will finish encoding and the window will disappear, but the step to combine and mux the files will not start. In task manager, the encoding window will sometimes show not responding. If I force it closed, the process continues and the file is created. Other times, nothing will be out of the ordinary in the task manager, and the only way to finish the encode is to manually combine the chunks and mux the files. Then I have to remove the job from the main window after closing and reopening RB (aborting causes it to hang).
Any ideas on what might be happening? I generally do large batches while AFK, so when one gets stuck it stops the entire process and I don't see it until hours later. It's been really slowing down my library updates.
Noisrevid
4th November 2021, 14:59
I've been having some issues recently with encodes hanging after completing the chunks. I use the batch encoder distributed among two servers (one on the main encoding PC and the other in a VM on my gaming PC). Sometimes the encodes will go through from start to finish and work properly, but other times the chunks will finish encoding and the window will disappear, but the step to combine and mux the files will not start. In task manager, the encoding window will sometimes show not responding. If I force it closed, the process continues and the file is created. Other times, nothing will be out of the ordinary in the task manager, and the only way to finish the encode is to manually combine the chunks and mux the files. Then I have to remove the job from the main window after closing and reopening RB (aborting causes it to hang).
Any ideas on what might be happening? I generally do large batches while AFK, so when one gets stuck it stops the entire process and I don't see it until hours later. It's been really slowing down my library updates.
I was testing distributed encoding last night and experiencing the exact same problem on videos that were longer than a certain point with hanging or systems that would go from IDLE to ENCODING over and over without figuring itself out.. Until eventually all 8 of my machines were hung up going from IDLE to ENCODE status.. Sometimes the issue would pop up immediately with the second chunk just not working at all 90% of the time. Adjusting the chunk size from 1 min to 2 min helps but it eventually breaks again. Let me know if you find the fix, maybe upping the chunk to 3+ minutes may help? I also don't know what "BDO Strength" means in the settings but it seems to be default to 1.0 and doesn't go higher, only lower.
Noisrevid
4th November 2021, 15:52
https://i.imgur.com/C3Yxtv5.jpg
Can Anyone Tell me Why There is some segments not Started or Not Completed,
Due to this My encoding Stopped on 99.4% and I Didn't Find any option to re-start That segments,
Please Help Me,
Same issue here.. eventually all my DE machines will freeze like this. @Atak, the TCP communication tab just constantly says [CLIENT -> SERVER] OK and [CLIENT <- SERVER] OK over and over when these freeze like this. There are no errors listed anywhere.. hitting Abort on the job cancels everything gracefully.
Atak_Snajpera
4th November 2021, 16:27
@Atak, the TCP communication tab just constantly says [CLIENT -> SERVER] OK and [CLIENT <- SERVER] OK over and over when these freeze like this. There are no errors listed anywhere.. hitting Abort on the job cancels everything gracefully.
Noisrevid is online now Report Post Reply With Quote
Copy whole log from TCP communication tab and paste somewhere (eg. https://pastebin.com/)
Ryushin
4th November 2021, 17:02
Just wanted to mentioned that I have not had a job hang in many months. It just runs now with no issues.
The only problem that I've been having is the encoded files sometimes have 1-2 white frames in them when the DE 1 minute chunks breaks on a screen transition. It's rare, but I've seen it happen about a dozen times or so for example when I encoded television season. Only way to see it to watch the whole season. I've mitigated this by changing my chunks from 1 minute to 5 minutes.
Noisrevid
4th November 2021, 17:06
Just wanted to mentioned that I have not had a job hang in many months. It just runs now with no issues.
The only problem that I've been having is the encoded files sometimes have 1-2 white frames in them when the DE 1 minute chunks breaks on a screen transition. It's rare, but I've seen it happen about a dozen times or so for example when I encoded television season. Only way to see it to watch the whole season. I've mitigated this by changing my chunks from 1 minute to 5 minutes.
Strange, and you're using all the latest and great Ripbot264 files? I'm starting to think the issue for me is going from existing x265 encodes to x265 encodes with DE.. I don't seem to have a problem with x264 -> x265 with DE.
Atak_Snajpera
4th November 2021, 17:29
Just wanted to mentioned that I have not had a job hang in many months. It just runs now with no issues.
The only problem that I've been having is the encoded files sometimes have 1-2 white frames in them when the DE 1 minute chunks breaks on a screen transition. It's rare, but I've seen it happen about a dozen times or so for example when I encoded television season. Only way to see it to watch the whole season. I've mitigated this by changing my chunks from 1 minute to 5 minutes.
What is your source video file? .TS .MKV? Could you load your file in SeekTester I made some time ago
https://forum.doom9.org/showthread.php?t=176878
Just make sure that you are using L-SMASH dll from RipBot264 and frame limit exceeds problematic point!
Noisrevid
4th November 2021, 18:09
x265 -> x265 Ripbot264 encodes are causing all my issues. Encode itself is 10x slower than Handbrake, DE fails eventually on longer movies, etc.
x264 -> x265 Ripbot264 is perfect.. Encode speed beats Handbrake using same settings and DE works flawlessly.
@Atak, sorry to spam with issues, I think your application is superior to Handbrake and i'd love to see you could see what's happening on my side with x265 -> x265 slowness and DE problems, can I provide any logs to help out here? I'd prefer to use Ripbot264 + DE..
Atak_Snajpera
4th November 2021, 18:12
Just run HWINFO in background and Process Hacker to check CPU temps/Clocks and memory usage.
Noisrevid
4th November 2021, 18:19
Just run HWINFO in background and Process Hacker to check CPU temps/Clocks and memory usage.
Already run HWinfo on all of my machines.. Temps are in check.. No WHEA errors.. everything's healthy. I guess there's an issue with the decoder in Ripbot264 for x265 content or something else getting in the way.
Can someone download a fresh copy of the latest Ripbot264 and do a x265 to x265 encode and compare to the latest with Handbrake?
I'm seeing the same behavior across 8 different machines. It's not a hardware issue.
Atak_Snajpera
4th November 2021, 18:55
Are you using GPU decoders in Ripbot264?
Noisrevid
4th November 2021, 19:01
Are you using GPU decoders in Ripbot264?
Tried both CPU and GPU in Ripbot264 with no change in speed.
Ryushin
6th November 2021, 14:36
What is your source video file? .TS .MKV? Could you load your file in SeekTester I made some time ago
https://forum.doom9.org/showthread.php?t=176878
Just make sure that you are using L-SMASH dll from RipBot264 and frame limit exceeds problematic point!
Source files are MKVs. I export the episodes using MakeMKV. Then use PowerDVD to identify and label them from the discs, then batch the episodes into RB. By the time I watch an episode and I notice it, the source files are deleted and gone from my ZFS snapshots. Since moving to five minute chunks I have not seen it happen, but that only means it will be five times less likely to occur now.
The next time it does happen, and I have the source still available, I'll do you what you ask.
Oscar77
9th November 2021, 17:18
I've been having some issues recently with encodes hanging after completing the chunks. I use the batch encoder distributed among two servers (one on the main encoding PC and the other in a VM on my gaming PC). Sometimes the encodes will go through from start to finish and work properly, but other times the chunks will finish encoding and the window will disappear, but the step to combine and mux the files will not start. In task manager, the encoding window will sometimes show not responding. If I force it closed, the process continues and the file is created. Other times, nothing will be out of the ordinary in the task manager, and the only way to finish the encode is to manually combine the chunks and mux the files. Then I have to remove the job from the main window after closing and reopening RB (aborting causes it to hang).
Any ideas on what might be happening? I generally do large batches while AFK, so when one gets stuck it stops the entire process and I don't see it until hours later. It's been really slowing down my library updates.
I have same problem with DE and 16 server
When i Launch multi encode with SD or 720p with 30 batch in queue i have no problem
But if i launch Batch in 1080P the first encode is ok but the second encode stop just after muxing operation and the service ClientEncode is green in task bar, if i lauch taskmanager and kill Clientencode the muxing is progress and after the third encode launch
http://prnt.sc/1ywwv2j
https://prnt.sc/1ywx3x7
https://prnt.sc/1ywx6yz
https://prnt.sc/1ywx93y
Pulp Catalyst
15th November 2021, 01:20
Is there a simple and quick way to get ripbot264 to detect when a film has a slight audio sync to it
some films start of fine, but as time goes on the sync gets worse, by the end of the film the audio sync is really bad.
is there nothing ripbot can do to detect this (staxrip on the same films does not have this issue?)
but i like ripbot because it's far simpler and much more reliable (stax is less reliable and also the hdr to sdr in ripbot is very good)
truth is, the interface in ripbot reminds me of "autogk"...good times
guest
15th November 2021, 03:40
Is there a simple and quick way to get ripbot264 to detect when a film has a slight audio sync to it
some films start of fine, but as time goes on the sync gets worse, by the end of the film the audio sync is really bad.
is there nothing ripbot can do to detect this (staxrip on the same films does not have this issue?)
but i like ripbot because it's far simpler and much more reliable (stax is less reliable and also the hdr to sdr in ripbot is very good)
truth is, the interface in ripbot reminds me of "autogk"...good times
Are the original source files "in sync" ??
May depend on what you are using to demux the files, RipBot uses L-Smash, but StaxRip has different options, AFAIK.
Pulp Catalyst
15th November 2021, 03:50
yes the originals are fine...handbrake works okay too, but i love using ripbot because the hdrtosdr is so good and the interface batch works amazing
one clue is that mediainfo lite reports on some of them (originals) things like "Delay relative to video : 5 ms" could this be the cause, and if so using batch mode where would i put this?
Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 2 h 1 min
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Delay relative to video : -9 ms
Stream size : 1.28 GiB (2%)
Title : Lord.of.war2003
Language : English
Default : No
Forced : No
guest
15th November 2021, 04:07
yes the originals are fine...handbrake works okay too, but i love using ripbot because the hdrtosdr is so good and the interface batch works amazing
one clue is that mediainfo lite reports on some of them (originals) things like "Delay relative to video : 5 ms" could this be the cause, and if so using batch mode where would i put this?
Is this only happening in batch mode ??
Are you using CPU or GPU decoding ??
There is an option to change the "delay" of the audio track, BUT if it isn't a constant delay, this won't help.
If this isn't a regular occurrence, you might have to remux the video & audio tracks after the RipBot encode is completed.
Ryushin
19th November 2021, 16:29
Is there a simple and quick way to get ripbot264 to detect when a film has a slight audio sync to it
some films start of fine, but as time goes on the sync gets worse, by the end of the film the audio sync is really bad.
is there nothing ripbot can do to detect this (staxrip on the same films does not have this issue?)
I have this issue with 4K discs that join multiple m2ts files (at least as a few months ago) into the video file. Whenever I encounter a 4K with branching, then I just use MakeMKV to make a single MKV file from the multiple m2ts files and import that MKV into RB and do what I normally do. This AV sync issue does not happen with Blu-ray and only 4K.
I also might add, that it occurred when using distributed encoding, but I have not tested that in over a couple of years.
fattestpizza
21st November 2021, 08:56
I've installed Ripbot on a new PC at home, and I'm having issues with it getting stuck when trying to open encoding servers. If I analyse the wait chain it's getsting stuck on rundll32.exe. If I close that process they start fine.
Also if I uninstall and reinstall avisynth+ the issue stops, but starts again when I reboot.
Any ideas?
Atak_Snajpera
21st November 2021, 11:03
Uninstall GeForce experience.
fattestpizza
21st November 2021, 12:59
Uninstall GeForce experience.
Thanks, but I don't have it installed. Before the rundll32 issue though I was having problems with RadeonSoftware.exe also holding it up, but I disabled the Radeon utility and that got past that. I'll actually uninstall it to see how it goes.
For what it's worth I'm using a laptop with a Ryzen 5800H APU and an RTX 3060.
Atak_Snajpera
21st November 2021, 14:22
Run windows in SAFE MODE
MCFish
22nd November 2021, 20:32
I've been having some issues recently with encodes hanging after completing the chunks. I use the batch encoder distributed among two servers (one on the main encoding PC and the other in a VM on my gaming PC). Sometimes the encodes will go through from start to finish and work properly, but other times the chunks will finish encoding and the window will disappear, but the step to combine and mux the files will not start. In task manager, the encoding window will sometimes show not responding..
I have the same problem, had it for some time now.
Have tried to use a clean install of windows and ripbot(as atak suggested), and used another computer as ripbot server. Still hangs randomly as you describe
sapphiresky83
23rd November 2021, 05:11
Hey all, I posted a few pages back but never had any replies, and so going to try once more.
Has anyone else run into the issue of a machine in your distributed encoding chain repeating the same chunks over and over again? I have 2 servers running on my desktop rig and they both will encode their assigned chunks, but then when they are finished, rather than grabbing the next in queue, they repeat the same chunks over that they already processed.
Here is a snipped from the activity logs of the encoding servers:
Encoding started...
""\\ROGSTRIX-Z390E\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\ROGSTRIX-Z390E\RipBot264temp\job1\Chunks\68.avs" -strict -1 -f yuv4mpegpipe - | "\\ROGSTRIX-Z390E\Ripbot264temp\tools\x264\x264_x64.exe" --seek 21 --colorprim bt709 --transfer bt709 --colormatrix bt709 --opencl --opencl-device 0 --opencl-clbin "C:\Users\jjbut\AppData\Local\Temp\EncodingServer1\x264_lookahead.clbin" --crf 20 --fps 24000/1001 --force-cfr --min-keyint 24 --keyint 240 --frames 1446 --sar 1:1 --level 4.0 --aud --nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --stdin y4m --output "\\ROGSTRIX-Z390E\RipBot264temp\job1\Chunks\68.264" -"
y4m [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation NVIDIA GeForce RTX 3070 Ti
x264 [info]: profile High, level 4.0, 4:2:0, 8-bit
[37.3%] 539/1446 frames, 28.23 fps, 9473.89 kbps, eta 0:00:32
[2021-11-22 23:02:32] Connection Closed Gracefully.
464|CLIENT -> SERVER| OK
465|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
466|CLIENT <- SERVER| OK
467|CLIENT <- SERVER| ENCODING_FINISHED
468|CLIENT -> SERVER| OK
469|CLIENT -> SERVER| GET_ENCODING_SUMMARY
470|CLIENT <- SERVER| OK
471|CLIENT <- SERVER| ENCODING_SUMMARY=192.168.0.245:1000 -> ERROR;CHUNK=68;CPU=94;RAM=33;DECODER=0;ENCODER=0;OTHER=94;ENCODING_PRIORITY=normal;
472|CLIENT -> SERVER| OK
473|CLIENT -> SERVER| STANDBY
474|CLIENT <- SERVER| OK
475|CLIENT <- SERVER| SERVER_IDLE
476|CLIENT -> SERVER| OK
477|CLIENT -> SERVER| ENCODE_CHUNK_68=\\ROGSTRIX-Z390E\RipBot264temp\job1\Chunks\68.cmd
478|CLIENT <- SERVER| OK
479|CLIENT <- SERVER| ENCODING_STARTED
480|CLIENT -> SERVER| OK
481|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=low;
482|CLIENT <- SERVER| OK
483|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.0.245:1000 -> Initializing encoding process...;CHUNK=68;CPU=42;RAM=36;DECODER=0;ENCODER=0;OTHER=42;ENCODING_PRIORITY=normal;
484|CLIENT -> SERVER| OK
485|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=low;
486|CLIENT <- SERVER| OK
487|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.0.245:1000 -> Initializing encoding process...;CHUNK=68;CPU=42;RAM=36;DECODER=0;ENCODER=0;OTHER=42;ENCODING_PRIORITY=normal;
488|CLIENT -> SERVER| OK
489|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=low;
490|CLIENT <- SERVER| OK
491|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.0.245:1000 -> Initializing encoding process...;CHUNK=68;CPU=42;RAM=36;DECODER=0;ENCODER=0;OTHER=42;ENCODING_PRIORITY=normal;
492|CLIENT -> SERVER| OK
493|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=low;
I've gone through settings over and over, have reinstalled the software many times and the required/supporting software as well.
Somewhat recently the machine in question had Windows 10 reinstalled fresh. I've done this many times before and have never run into this particular issue before.
Thanks in advance to anyone who might be able to assist!
Atak_Snajpera
23rd November 2021, 15:20
I suspect that encoder did not encode all frames. Encoding server always checks at the end if number of encoded frames match number of frames to encode. Checks 68.txt file located in chunks folder
Ps. Try again without opencl acceleration in x264.
Dhry
23rd November 2021, 18:42
Hi. Sorry, not sure if this has been asked before.
I have a render farm with several servers, some of which are nice and fast, others which aren't so fast. For any given job, I find that what happens is most of the servers complete their chunks of work, but then they all have to sit around twiddling their thumbs while the last one or two servers crunch their chunk before it's time to move on to the next job.
Is there a way to allow the idle servers to just move on to the next job in the queue and start their business, while the slow servers at the end of a job just finish what they're doing? If not there's a potential huge waste of idle server time toward the end of each job. See attached screenshot for example.
Cheers
Dhry
Atak_Snajpera
23rd November 2021, 20:47
Hi. Sorry, not sure if this has been asked before.
I have a render farm with several servers, some of which are nice and fast, others which aren't so fast. For any given job, I find that what happens is most of the servers complete their chunks of work, but then they all have to sit around twiddling their thumbs while the last one or two servers crunch their chunk before it's time to move on to the next job.
Is there a way to allow the idle servers to just move on to the next job in the queue and start their business, while the slow servers at the end of a job just finish what they're doing? If not there's a potential huge waste of idle server time toward the end of each job. See attached screenshot for example.
Cheers
Dhry
No...
guest
24th November 2021, 02:44
Hi. Sorry, not sure if this has been asked before.
I have a render farm with several servers, some of which are nice and fast, others which aren't so fast. For any given job, I find that what happens is most of the servers complete their chunks of work, but then they all have to sit around twiddling their thumbs while the last one or two servers crunch their chunk before it's time to move on to the next job.
Is there a way to allow the idle servers to just move on to the next job in the queue and start their business, while the slow servers at the end of a job just finish what they're doing? If not there's a potential huge waste of idle server time toward the end of each job. See attached screenshot for example.
Cheers
Dhry
This HAS been asked about before, and got the same answer as given in the previous post.....
However, you can enable a "sleep" function, that (when it works), puts the idle PC's to sleep, and then when the next job starts, the "sleeping" server(s) hopefully wake up, and start encoding.
I tried this not so long ago, and had limited success...it's just one of the problems when running so many servers, unfortunately.
I feel your pain.
Sveni-go
2nd December 2021, 10:12
Hi,
Is there any way that Ripbot convert DTS in DD+ automatically ? or implemented in Audio
FuzzyNutz
2nd December 2021, 20:34
Please make RB work well with Windows scaling and give us a dark mode.
Scaling is common for 4k display users and dark mode is the new norm for peeps in the know. Non-dark mode is so last century. "Once you go black, you never go back!"
-I'm aware the Windows compatibility high DPI scaling override setting "System (Enhanced)" for RB's executable file provides a decent workaround for most areas of RB's gui, but the lower window for bottom-right cropping on page 1 of the "AviSynth Filters" section as well as MPC become dysfunctional.
FuzzyNutz
2nd December 2021, 21:09
Please add an option for vbr (vs cbr) for AAC and the ability to choose the vbr number. For now, I manually edit the "jobX_EncodeAudioX" file to get vbr6.
An option to choose cbr numbers beyond 320 would be great, too.
-I understand 5.1 @ 320 and 2.0 @ 128 are transparent.
FuzzyNutz
2nd December 2021, 21:16
Please add, perhaps in the settings area, the ability for prepopulated user defined data for track descriptions. So, users don't have to manually enter often used descriptions. Each track type, (video, audio and subtitle), should have it's own prepopulated user defined descriptions list. Also, users should be able to control the order of the descriptions within the lists (vs the order being automatically alphabetical).
And make it so, if the description box for subtitle tracks is empty, nothing from the source file gets injected in the resulting track.
FuzzyNutz
2nd December 2021, 21:40
When a source containing a dts-ma track is loaded, RB displays a dts symbol above the top-right of the selected audio track. I hope that's not an indication RB is encoding from the core (vs the full dts-ma).
FuzzyNutz
2nd December 2021, 22:00
Please implement the ability for RB to only choose sample frames that don't have video info that's too dark, in proximity to the crop line, when "new frame" is used in page 1 of the "AviSynth Filters" section.
Pulp Catalyst
3rd December 2021, 06:00
Is there a simple and quick way to get ripbot264 to detect when a film has a slight audio sync to it
some films start of fine, but as time goes on the sync gets worse, by the end of the film the audio sync is really bad.
is there nothing ripbot can do to detect this (staxrip on the same films does not have this issue?)
but i like ripbot because it's far simpler and much more reliable (stax is less reliable and also the hdr to sdr in ripbot is very good)
truth is, the interface in ripbot reminds me of "autogk"...good times
edit
so i found a movie that i have ripped twice now, ripbot always gets a audio sync with it as time goes on in the video
its "wreck-it Ralph"
at the beginning it's okay, by the time in the end it's about 3-5 seconds off.
i ripped disk with makemkv then tried dvdfab
same results
is there something on these types of movies that ripbot is not detecting?
it compressed fine with stax and handbrake
but the quality of handbrake on movies is really subpar, and staxrip doesn't do easy out of the box hdr to sdr without getting into user intervention with parameters.
in ripbot i always use batch processing
Atak_Snajpera
3rd December 2021, 19:08
Is numer of frames the same in video encoded by ripbot and staxrip/handbreak?
Two possibile scenarios:
1) some frames are being dropped during encoding
2) slightly wrong framerate in encoded file
guest
4th December 2021, 01:23
edit
so i found a movie that i have ripped twice now, ripbot always gets a audio sync with it as time goes on in the video
its "wreck-it Ralph"
at the beginning it's okay, by the time in the end it's about 3-5 seconds off.
i ripped disk with makemkv then tried dvdfab
same results
is there something on these types of movies that ripbot is not detecting?
it compressed fine with stax and handbrake
but the quality of handbrake on movies is really subpar, and staxrip doesn't do easy out of the box hdr to sdr without getting into user intervention with parameters.
in ripbot i always use batch processing
I would like to suggest the following "test"...
Demux the original "ripped" file to separate the audio & video tracks, THEN do the same to the file you've encoded with RB, then using MKVToolNix, import the RB encoded video file, and the original ripped audio file, and remux then back together, and see if it's still out of sync.
As mentioned in the previous post, it's something to do with frames or framerates.
Maybe you could try a different process of ripping the disc, maybe MakeMKV is the problem.
NiGHTsC
4th December 2021, 08:51
anyone having problem previewing MP4 because of LSMASHSource.dll?
64bit issue when it's 32bit version, and 32bit issue when I switch to 64bit version....
Cannot load a 32(64) bit DLL in 64(32) bit Avisynth
Also, how do I fix some out of sync issue with convertfps now? since it's now LWLibavVideoSource instead of DirectShowSource
Thank you.
guest
4th December 2021, 09:43
anyone having problem previewing MP4 because of LSMASHSource.dll?
64bit issue when it's 32bit version, and 32bit issue when I switch to 64bit version....
Cannot load a 32(64) bit DLL in 64(32) bit Avisynth
Also, how do I fix some out of sync issue with convertfps now? since it's now LWLibavVideoSource instead of DirectShowSource
Thank you.
If you want to try a different decoder, do this, and see if it fixes your issue:-
overwrite this field in RipBot264.ini if you want to use FFMS2 instead of L-Smash
[DefaultVideoDecoder]
MPEG-2=FFMS2
VC-1=FFMS2
AVC=FFMS2
HEVC=FFMS2
OTHER=FFMS2
NiGHTsC
4th December 2021, 18:01
If you want to try a different decoder, do this, and see if it fixes your issue:-
overwrite this field in RipBot264.ini if you want to use FFMS2 instead of L-Smash
[DefaultVideoDecoder]
MPEG-2=FFMS2
VC-1=FFMS2
AVC=FFMS2
HEVC=FFMS2
OTHER=FFMS2Love you!
gabbett1
5th December 2021, 16:02
Just installed the new version and could not get the distributed encoding to work. The encoding clients are open on the other computers, however Ripbot perpetually says "connecting" and just hangs there. I should also note that one of the encoding servers is the computer itself with Ripbot and it will not encode either.
guest
6th December 2021, 00:46
Just installed the new version and could not get the distributed encoding to work. The encoding clients are open on the other computers, however Ripbot perpetually says "connecting" and just hangs there. I should also note that one of the encoding servers is the computer itself with Ripbot and it will not encode either.
What new version ???, latest is v1.26.1
If you're running an nVidia GPU, the issue is more than likely the driver software.
Check this post for what to do to fix the problem:-
https://forum.doom9.org/showthread.php?p=1955821#post1955821
And maybe read the posts just before & after.
guest
6th December 2021, 00:50
Hi,
Is there any way that Ripbot convert DTS in DD+ automatically ? or implemented in Audio
I don't think you got a reply.
You might be better off converting your audio "outside" of Ripbot, and muxing it back in later, just let RipBot encoding the video track(s).
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.