I tried out MakeMKV and then encoded the episode. The video is noticeably sped up. Like it's running at 1.25x speed. Although the audio sounds like it is at the correct speed, so it is obviously delayed behind the video. The .mkv from MakeMKV plays at normal speed with the audio in sync. I opened the .mkv from MakeMKV and the encoded .mkv from StaxRip in MediaInfo and it says they are both 29.97 FPS.
Also, the first episode I had originally encoded with StaxRip that played correctly also had sped up video after encoding it using the source from MakeMKV.
+ Reply to Thread
Results 31 to 60 of 458
I don't have real NTSC experience, any chance you could upload the first VOB file to a cloud drive? I believe you have two choices with NTSC, either use a tool that has some NTSC smarts built in like Handbrake or MeGUI, or good understanding of NTSC field processing, AviSynth and StaxRip.
Traditionally NTSC DVDs are processed with DGMPGDec, much info about it can be found in forums, guides and the documentation:
If mkv and ffms2 or l-smash-works is ideal for all kind of NTSC material I don't know.
I've uploaded the second .vob actually.
If I preview and cut in Staxrip up to about the 15 minute mark where the episode ends and the next one starts, the audio is in sync with the video. If instead I start the cut at the beginning of the second episode then the audio and video are out of sync.
It's like something has changed in between where one episode ends and the next one begins.
Thanks for taking a look. I'll do some reading about DGMPGDec and NTSC.
Last edited by falcon42; 18th May 2015 at 21:57.
Thanks for uploading, unfortunately it was already locked when I saw it due to being accessed to often.
Google Drive still stays file is locked due to being accessed to often and that I should try later. If you edit your post removing the link it will hopefully work again after a while. Dropbox also locks files if accessed to often so it's better to use private message.
I'm releasing a new pre-release build today, a pre-release isn't tested by me so potentially has more issues then a beta, I hope it's mostly fine.
StaxRip x64 18.104.22.168 pre-release (2015-05-15)
- Added DGAVCIndex as AVC TS demuxer, dsmux is still available but disabled by default
- Added plugin flash3kyuu_deband v1.5.1
- Added QSVEncC hardware decoding bypassing AviSynth and using StaxRip's cut/trim and crop values. On my Win10 development OS it don't work however and I didn't test on Win7
- Changed DGIndex to demux and output m2v because DGDecode does not work on Win10, this means the old DVD workflow is fully supported again, MakeMKV is still recommended instead
- Instead of always adding AssumeFPS it's now only added if necessary
- The Applications dialog was renamed to Apps and Version and Description info was improved (only 50% completed)
- Improved AviSynth editor and filter profiles
- Improved 'Just Mux' feature supporting more formats
- Fixed qaac executed with command window, improved qaac description in applications dialog
- Fixed crash in preview window caused by AviSynth, StaxRip shows a error message instead now
- Fixed crash caused by stream title containing character that are illegal in windows file system
- Fixed two bugs in the 'Execute Command Line' command of StaxRip's command engine which powers StaxRip CLI, various menus and event commands
- Updated MP4Box to 0.5.2-DEV-rev376 static mingw build, I made some basic tests which succeeded, Selur said -hint don't work but nobody ever requested -hint support in StaxRip.
- Updated MKVToolNix 7.9.0 x64
- Updated nnedi3 0.9.4.9 x64, nnedi3 and DGDecNV are now working on Win8 and Win10, DGDecNV 2049 has to be re-downloaded
- Updated AVSMeter 2.0.2 x64, the main menu can be customized to add custom CLI switches
- Updated qaac 2.48 x64 and improved integration
- Updated l-Smash-Works 785 x64
StaxRip x64 22.214.171.124 pre-release (2015-05-19)
- Added x265 switch --output-depth to choose between 8bit and 10bit output
- Improved 'Demux Configuration' dialog
- Fixed and changed cropping and resizing with QSVEncC, there is now for both crop and resize a special AviSynth filter profile 'Hardware Encoder' but if AviSynth is bypassed by enabling hardware decoding in QSVEncC then it's not necessary to use this special profiles, any crop or resize profile will do in this case.
- Fixed bug audio streams not being detected for M2TS files
- Updated x265 to x265_1.7+2
- Updated QSVEncC to 2.0 beta 3
hello can someone help me with this problem in staxrip
i cant convert video with audio all togther so i disable audio and convert video only
Error Mux AAC to M4A
Mux AAC to M4A failed with exit code -1073741701
StaxRip.ErrorAbortException: Mux AAC to M4A failed with exit code -1073741701
at StaxRip.Proc.Start() in C:\Daten\Projekte\VS\VB\StaxRip\General\Proc.vb:li ne 226
at StaxRip.Audio.DemuxMKV(String sourcefile, AudioStream stream, AudioProfile ap) in C:\Daten\Projekte\VS\VB\StaxRip\General\Audio.vb:l ine 159
at StaxRip.Audio.Process(AudioProfile ap) in C:\Daten\Projekte\VS\VB\StaxRip\General\Audio.vb:l ine 33
at StaxRip.MainForm.Encode() in C:\Daten\Projekte\VS\VB\StaxRip\Forms\MainForm.vb: line 2273
at StaxRip.MainForm.RunJobRecursive() in C:\Daten\Projekte\VS\VB\StaxRip\Forms\MainForm.vb: line 3630
MP4Box fails here to mux aac to m4a, maybe you can upload the source an send me a private message with the link. I just recently switched to using a static MP4Box build so maybe you have luck with an official build:
If a official build don't work either then I can't do much but I would still be interested to see media info for this file.
The static build has problems with certain files then. I'm afraid I have to revert to the official build.
I am new to the StaxRip forum (but not StaxRip) so pardon me if I have repeated a previously answered question and/or request. I have reviewed entries in the forum but did not come across anything related to my question.
I have created a Startup template that I use more often than not across all video. It is straightforward and the VBR fixed, not file size. The template loads fine. However, the VBR is reset after source file scan and overrides the load template VBR setting. I have to REMEMBER to reset back to original value!
I believe I understand why. Today, the program prioritization is based on file size, and is programmed to maintain the file size initially calculated upon loading. This calculation is inaccurate since it only has knowledge of VBR (since I set it in the Startup template), prior to source file scan.
Am I missing something to avoid this from happening?
Thanks in advance.
I'm not sure what you mean with VBR, the mode setting in the x264 dialog has a old description using common terms, it should still be valid today:
Generally there are two popular encoding modes, quality based and 2pass. 2pass mode allows to specify a bit rate and file size, quality mode doesn't, it works with a rate factor and requires only a single pass. Other terms for quality mode are constant quality or CRF mode in x264.
Slow and dark sources compress better then colorful sources with a lot action so a short, slow and dark movie requires a smaller file size then a long, colorful source with a lot action and movement.
Quality mode works with a rate factor that gives comparable quality regardless of how well a movie compresses so it's not using a constant bit rate but adjusts the bit rate dynamically. So while the same rate factor can be applied to every movie to achieve a constant quality this is not possible with 2pass mode because every movie requires a different bit rate. Quality mode is much easier to use then 2pass mode which requires a longer encoding time due to 2 passes and a compressibility check to be performed to determine a reasonable image and file size which also requires more expertise.
It's a common misconception that 2pass mode is more efficient than quality mode. The only benefit of 2pass mode is hitting a exact file size. Encoding in quality mode using a single pass will result in equal quality compared to a 2pass encode assuming the file size is identical of course.
Quality mode is ideal for hard drive storage and 2pass mode is ideal for size restricted mediums like CD's and DVD's. If you are still not sure which mode to use then it's probably better to use quality mode.
Thank you for the fast response.
Let me attempt to restate my issue so as not to get caught up in terminology. I absolutely understand what you are saying. I am familiar with both approaches, that is, CRF, and 2 pass. I am referring to 2 pass mode but fixated on bit rate not file size. I am not concerned about storage requirements but I am concerned about bit rate in a streaming environment. I have found that a video bit rate from 3000 to 5000, and worst case, coupled with two DTS audio streams, gives me consistent streaming results. I am NOT saying it produces the highest quality video. However, on a 60" HDTV, and streamed through an OPPO and/or Pioneer network blu ray player, the quality is outstanding and more than adequate for us.
All I am asking is that the video bit rate NOT be reset after the source file scanned in order to maintain an irrelevant (in my case) file size.
Is this making sense now? Thanks again.
You should be using CRF + vbv-maxrate/bufsize anyways. 2pass does not limit the bitrate in a way that ensures proper streaming.
I always had doubts in targeting bitrate and therefore never added direct support.
How you workaround it:
In the x264 or x265 dialog you can find a option to add custom command line switches where you can add your bitrate.
Alternatively you can use Tools/Advanced/Event Commands setting the bitrate after the source it loaded.
Best approach is probably sneaker's suggestion.
Last edited by stax76; 31st May 2015 at 20:42.
Thanks Sneaker! Not familiar with the option you recommend but after some research it sounds appropriate albeit somewhat hit and miss with setting both parameters.
Do you have idea as to an average device buffer size? Is it hundreds of MB, 1GB, etc.
Also, shouldn't I be more concerned about average network bandwidth in setting vbv-bufsize since the combination of "maxrate" and "bufsize" determine momentary / burst bit rates allowed?
Average network bandwidth is meaningless. You need to set your minimum network bandwidth as "vbv-maxrate" (but not higher than your device can decode) and then try different buffer settings. Basically if buffer = maxrate that means the buffer can hold 1 second of data. Try different settings between 1 and 10 seconds, I guess. For tests you want to make sure the settings are totally maxed so instead of --crf you set --bitrate == --vbv-maxrate. If there are dropouts you need to decrease the values.
But now I see you didn't say anything about WiFi? If it's a wired LAN (>= 100 Mbit/s) the players will be the limit, not the network.
In that case you probably don't have to test much, I assume something simple should do the trick:
x264 input -o ouput --crf 18 --level 4.0 --vbv-maxrate 24000 --vbv-bufsize 24000
You can then increase or decrease crf if quality is too high/low. But replacing --crf with --bitrate + --pass like you did before is also ok. vbv also works with --bitrate and n passes.
But as I said I somehow assumed you did all that because of WiFi. Maybe I understood your whole post wrong and my tips are useless.
Last edited by sneaker; 1st Jun 2015 at 07:20.
First of all, your tips are not useless. I am definitely learning something here.
Sorry for the confusion. I have no use for wireless - the results too inconsistent - too many variables given the network is shared. I agree with your statement in general regarding average network bandwidth, but in a shared / high average usage, vaguely defined LAN, network congestion does play a role and can be the cause of unpredictable behavior with high bit rates I have found.
What should the effect be of your suggestion: --bitrate + n passes + vbv? Does it set an upper limit on bit rate beyond the actual setting, e.g. --bitrate 3000?
FYI - I have already tried the following. CRF 18 vbv-maxrate 4000 vbv-bufsize 2000. Interestingly, the average bit rate generated is just over 3000. Is this what you would have expected from the settings above?
I found this on the x264 development site. I thought the summarized explanation of CBR, CRF, along with VBV settings sheds additional light on the considerations for streaming.
Just to wrap this up:
If I am in a hurry and need to encode files for streaming I can use:
CBR one pass mode
- Lowest quality (at least in my tests gives lowest SSIM 0.9815)
- Resulting bitrate was lower than the desired (975.80kbps)
e.g. x264 --vbv-bufsize 2000 --vbv-maxrate 1000 --bitrate 1000 -o <output> <input>
CRF + VBV
- Second in quality (second largest SSIM 0.9818 in my tests)
- Resulting bitrate was even lower (960.16kbps). Maybe a lower CRF
would have given better SSIM and higher bitrate?? but...
- I have no idea how to select CRF value. Some forums say 18 is
the best bet.
e.g. x264 --vbv-bufsize 2000 --vbv-maxrate 1000 --crf 18 -o <output> <input>
If I have time to spend and need to encode files for streaming then:
2 Pass Encode:
- Gives the highest SSIM 0.9822 in my tests
- Resulting bitrate is very close to the desired (1001.99 kbps)
- The slower one because of two pases.
e.g. x264 --pass 1 --bitrate 1000 -o <output> <input>
x264 --pass 2 --vbv-bufsize 2000 --vbv-maxrate 1000 --bitrate 1000 -o <output> <input>
CRF with second pass CRF + VBV
- Just for testing but gave results similar so single pass CBR and
as slow as 2pass so better stick with 2pass encode.
e.g. x264 --pass 1 --crf 18 -o <output> <input>
x264 --pass 2 --vbv-bufsize 2000 --vbv-maxrate 1000 --crf 18 -o <output> <input>
If I only care about quality and bitrate/storage/time are no problem then
CRF is the way to go:.
- With CRF 18.0 gives very high SSIM 0.9900 but bitrate is
- With CRF 23.0 gives SSIM 0.9835 and bitrate 960.46kbps
CRF is just an arbitrary number to control average bitrate/quality. Low quality/bitrate = high crf, high quality/bitrate = low crf. Just play around until you find a value you like. There is no "best crf value".
You almost never want to use CBR. This is only useful for very few things, e.g. you want to stream constant 2 Mbit/s over a 2 Mbit/s Internet connection so the bandwidth is 100% utilized. It has nothing to do with being "in a hurry". It is not faster than VBR. If you are in a hurry but want to hit a certain bitrate just use --bitrate but without --pass. Choose the same vbv values as you would usually use.
And again: you don't want to choose maxsize/bufsize values as low as 1000. It's way too low (unless streaming over 1 Mbit/s Internet connection). Never use vbv values to regulate average bitrate, it's only to ensure there are no momentary spikes beyond what your network or player can handle.
P.S.: Maybe a mod can move this? We are kinda spamming the StaxRip thread with off topic talk.
It took me a while to get a better grip of NTSC and adjusting StaxRip, I've uploaded a test build today with a new NTSC related feature:
You use it like this:
- Rip DVD with MakeMKV
- Open MKV and choose Automatic or FFVideoSource, either way FFVideoSource will be used
- Double-click on any filter in order to open the new AviSynth editor, right-click the code of the source filter (FFVideoSource), now you can see 3 rffmode parameter menu options that deal with NTSC
You still need basic NTSC understanding, the script editor has a play feature that might help and there are filter profiles included that are interesting for NTSC users:
for IVTC: Telecide(guide=1).Decimate()
to remove remaining combing: = vinverse2()
The new parameter feature is also available for DGSource crop, resize and deinterlace, the parameters are currently defined in my code, it would be possible to define it with json or xml if anybody wants to help to define more parameters for other filter functions.
Did you try StaxRip recently? How does it look like from the view of a expert like you? I recently started to add features for people who prefer a manual workflow, users are asked now which source filter should be used when opening a file. What comes next is showing a demuxing dialog for formats like MKV and MP4. It will be similar to the eac3to demuxing dialog that is only enabled for Blu-ray folders and M2TS files.
Last edited by stax76; 11th Jun 2015 at 11:03.
I want to add more filters but I'm still thinking about how to do it best because download size is always a consideration, in recent days I was already thinking a lot about distribution because the next release will feature VapourSynth support so finally popular scripts like QTGMC will be usable so yes, I hope I'll find a solution soon.
StaxRip x64 126.96.36.199 beta (2015-06-25)
- New: Added full first class VapourSynth support including plugins and profile for QTGMC
- New: Added possibility to switch dynamically between any source filter back and forth including DGSource and DGSourceIM. Indexing is triggered automatically in case no index file is present
- New: Added vinverse plugin to remove residual combing from NTSC
- New: Added GUI for demuxing MKV and MP4
- New: Added feature to easily enable certain parameters for certain filters in the AviSynth editor. Currently supported are FFVideoSource and DGSource, more parameters and filters might be supported on request. Use it by right-clicking on FFVideoSource or DGSource in the AviSynth editor, the menu shows then NTSC options and hardware cropping and resizing options.
- New: Added Play option for MPC playback in the AviSynth editor
- New: Added two new options in the dialog to define files for batch processing to add a entire folder and a entire folder including sub-folders
- New: Added new subtitle UI based on data view
- New: Added option to generate subtitle names based on the subtitle language
- New: x265 switch --limit-refs added
- Fix: Disabled audio demuxing for MKV and MP4 by DGIndexNV and DGIndexIM because it's already demuxed by MP4Box and mkvextract
- Fix: Tools/Directories/Plugins wasn't pointing to the AviSynth+ plugin directory
- Fix: Wrong command line generated for --deblock
- Update: QSVEncC 2.0 beta 11
- Update: x265 1.7+234
- Tweak: DTS bitrate is now unrestricted
- Tweak: Moved field processing filters to dedicated category like before in StaxRip x86
- Tweak: Replaced LinkLabels with Buttons in eac3to dialog
- Tweak: The help for all included AviSynth plugins can now be accessed per menu in the AviSynth editor
- Tweak: ProjectX is enabled by default in case Java exists, other dsmux will handle MPEG-2 TS
- Tweak: In the dialog to define files for batch processing the 'Create Jobs' option was renamed to 'Demux and index before adding jobs', regardless of if this option is enabled jobs are always created
- Tweak: Removed x86 and VS C++ 2013 from AviSynth+ installer bringing it from 18 MB down to 4 MB. Very often VS C++ 2013 is already installed and in case it ain't already installed StaxRip will show the Apps dialog which has a download button for VS C++ 2013.
- Tweak: replaced avs4x26x with ffmpeg
The installer includes both 32 bit and 64 bit.
Is sneaker and sneaker_ger the same user?
Yes, the VapourSynth installer includes x64 and x86 but what you see or can install might depend on what Python version you have, if you have only Python x86 then the VapourSynth installer might only show x86 (I'm not sure). At this moment you want Python x64 3.4.3, unfortunately it can be somehow difficult to find the right Python version, I don't know how I can make this easier, this is the download link for Python x64 3.4.3: