StaxRip x86 (development for x86 has been stopped) [Archive] - Page 40

trueimage

14th June 2008, 00:29

Well, maybe the speed won't be there, but a VMWare install of XP 32-bit will tell me if it works, then I can decide to install it on this box or not...

I thought ProjectX was a preparation step built-in? Should I do something to it first before I try StaxRip? I really want these in x264 mkv for storage, the 18GB+ file size is a bit excessive, esp when they could be 5-8 GB easy...

stax76

14th June 2008, 00:43

I've never seen such a split/filename/filetype pattern before, by default StaxRip probably can't open the files directly to prepare them, it might be possibly to configure StaxRip to do so. You can try to demux/index manually using DGIndex. You get then a d2v file and audio which StaxRip can open. If you get problems like sync issues you can try to demux with ProjectX before you index with DGIndex. I always demux using ProjectX and since many years, it's very robust.

Sharc

14th June 2008, 09:01

..... If you get problems like sync issues you can try to demux with ProjectX before you index with DGIndex. I always demux using ProjectX and since many years, it's very robust.
In fact I experienced many sync issues (say in 50% of the cases) when merging vobs of a VTS using the default method. Following your advice I re-tried a critical case using ProjectX for demuxing, then running DGindex on the m2v and selecting the audio produced by ProjextX. It seems to have solved the problem. So why not use ProjectX as StaxRips default demultiplexer and automate the process? Just some thoughts.

stax76

14th June 2008, 10:32

DGIndex works fine on VOBs, your sync issues are extremely rare, if you search the forum I don't think you'll find much about it, was your source a copy or a original? Only time that happened to me was a copy I made with DVD Shrink or Nero, I didn't find a way to fix it, it was so bad that even PgcDemux and VSRip returned a error so I ripped the original again using RipIt4Me, it had still a sync issue of 8 seconds because of nasty authoring, DVD started with a 8 second ad without sound, not many DVD's are authored like this and I wish DGIndex could fix that. I solved it cutting off the ad using DVD Shrink reauthor mode, now that I think about it it would have been easier to cut it with DGIndex.

ProjectX might not be popular outside of the DVB scene, at times there wasn't great alternatives, it was created because all previous tools sucked badly. VOB support was added rather late probably because the author was bored. Reasons why it's not so popular might be no binaries, no active development, difficult interface, Java requirement. It's a great tool however, I use it since the beginning, it's about 7 years old like StaxRip and it has never failed on a stream I recorded with DVBViewer.

Sharc

14th June 2008, 11:22

Source is ripped from original DVD with RI4M. Ripping it again with AnyDVD did not make a difference. Sync loss (=incorrect delay) is typically in the range of 200 ... 500ms when it happens. It can happen for the entire movie, or only for a part of it, say starting in the 2nd half or so.
I tried to find a systematic reason when this happens, no clear conclusion so far. In one case the reason was probably some intro ads at the beginning of the first vob. When skipping these intros with DGindex manually, sync was ok. In one case the delay of the first vob was insane: some 87000ms. Skipping one GOP with DGindex set the delay correctly. In one case the sync loss started in the middle of a vob for no obvious reason. Batch processing the individual vobs instead of merging mitigated the problem. It appears that ProjectX handles these cases safely, I would need to do more tests however. I admit that I was "intimidated" a little by ProjextX at the beginning .....
Thanks for your explanations.

stax76

14th June 2008, 11:52

or only for a part of it, say starting in the 2nd half or so.

Starting 2nd half only happened once too me and before you I've never read about it. What I've often read about is sync issue develops towards the end but I've never experienced it. Loosing sync in the middle is nasty so I hope it won't happen again or a reason can be found.

Sharc

14th June 2008, 22:55

Now I had a new sync issue:
Audio Track 2 (en): Perfect sync
Audio Track 1 (de): Out of sync by 12 seconds.
First vob starts with a WB logo intro (vob1 cell1 of 12 seconds duration). The audio of this intro is missing in Track 1 (de), i.e. it started immediately with the audio for the movie. Hence the (de) audio is early by 12 seconds.
=> I'll try again using ProjectX for demuxing.

Added:
ProjectX managed to align the two audio language tracks correctly with the movie, although the audio for the intro clip is missing in the (de) track.

Added 2:
Ok, here how I finally solved this problem using DGIndex. It needs little manual work.

1) Open DGIndex and load (File open .... ) all the vob files belonging to the title.
2) Advance with the > button until the first cell of the movie appears (see DGindex window tiltle bar), i.e. skipping the VOB ID (VOB1 cell1 in my case) of the studio intro.
3) Press the [ button
4) Save the project
5) Now load the d2v generated by DGIndex in step 4) into StaxRip and continue as usual.
The 2 audio tracks are now both in sync with the video, the studio intro is skipped.

Sharc

19th June 2008, 07:00

I am using Xvid in DivX container for material which I want to playback on my SAP. Quantizer 2 with qpel delivers very nice quality.
It seems however that DivxMux (the muxer used by StaxRip for DivX container) has a problem when the filesize exceeds about 4GB, yet still would fit on a DVD5. No error message or warning, the movie is just truncated, and search/random access becomes a problem. It seems to work well for file sizes below 4GB.
Does anyone have similar experience? Is there a limitation?

arrirc

26th June 2008, 18:11

Hello Stax

Please find the crash report here (reference: http://forum.doom9.org/showthread.php?p=1152658#post1152658):

http://www.mediafire.com/?dyyuiy3uxz3

stax76

26th June 2008, 20:42

arrirc

27th June 2008, 13:51

Hi,

It's crashing trying to minimize a external application, what external application runs when this happens? I've uploaded a beta trying to fix it but since it's not clear what's causing it I can't promise much.

Thank you very much Stax.
I believe the application was Firefox 'cause thats the only program that was running while I was using StaxRip.

Now may I request your attention to a doubt that I have? I have recently converted a Video which was ripped on my HDD, to MP4-X.264 combination. First I tried the profile under Constant Quality> ASP Q2 eq (crf) and next time I have used High Quality> Slow CRF 22.

For the same movie, which is BW, the first profile yielded a file of 1.8GB in size (approx) and the second profile resulted a much smaller file size (about 900 MB). While using these profiles, in both cases, the "compressibility check" option did not appear.
Is this size difference Normal?

stax76

27th June 2008, 15:19

Is this size difference Normal?

In the x264 dialog, press the F1 key and work through the guides, what you are most interested is CRF Mode. CRF 22 gives you a good balance between filesize and quality, CRF 18 gives extreme quality/filesize.

arrirc

27th June 2008, 15:39

Thank you Stax, I shall let you know in a day or two.

So the 900MB file is good enough as a archive/backup, and so is the "High Quality> Slow CRF 22" profile- right?

stax76

27th June 2008, 16:47

It's well balanced assuming you don't use a resize filter.

arrirc

27th June 2008, 18:52

It's well balanced assuming you don't use a resize filter.

I did not have to resize in the first case, but I did resize in the second case, I am not in front my own PC, so I can't recall the exact WxH, but most probably the W=702! What's wrong with the resize? If I encode taking 720x480 or 720x576, will the file sizes be considerably larger?

Now a little off topic: I must admit that I am greatly impressed with your software and you mostly. Your promptness in responding to even flimsy/ silly issues that we newbies bring forward is commendable. Please accept my heartfelt gratitude. Thank You!

----------------
Now playing: Cliff Richard - True Love Ways (http://www.foxytunes.com/artist/cliff+richard/track/true+love+ways)
via FoxyTunes (http://www.foxytunes.com/signatunes/)

stax76

28th June 2008, 11:12

@arric

You can use the same CRF value for any image size, for small image sizes I would probably lower the CRF value in order to improve the quality. I appreciate your gratitude!

@all

If you want to help testing the beta, this is the current status:

* Some new MKV features added
* Tooltip added to tray icon showing console output
* Preparers can define which formats to be used and which not
* Various aspect ratio fixes and improvements
* VirtualDub updated to 1.8.1
* DGAVCDec updated to 1.0.0a24
* Many fixes and Improvements regarding various source formats
* Pass through encoder improved to handle not only previously encoded project but also source files
* Since the pass through encoder was improved StaxRip can now be used to (batch) remux source files.
* MediaInfo updated to version 0.7.7.2, it fixes reading aspect ratio from anamorphic avi source files
* Some fixes and improvements picking up audio files
* Added MP4 demuxing, improved MKV demuxing
* Added support for more then one IDX (vobsub) file
* Added support to reorder IDX (vobsub) subtitles
* DGAVCDec was updated to version 1.00a23
* Various setup fixes and improvements
* Many useful directories added to the main menu
* A couple of improved tooltips
* Fixed two bugs with adding jobs from a second StaxRip instance
* New command to play a sound file

Ajax_Undone

28th June 2008, 17:35

http://img90.imageshack.us/img90/7405/derstt6.jpg (http://imageshack.us)
http://img90.imageshack.us/img90/7405/derstt6.4a530b555b.jpg (http://g.imageshack.us/g.php?h=90&i=derstt6.jpg)

Hey Stax whats with the 3.5GB VB Script in the out folder...

stax76

28th June 2008, 17:57

Hey Stax whats with the 3.5GB VB Script in the out folder...

I've absolute no idea what happened, maybe I can see something if you upload the diagnostic file (Help / Make Bug Report) using 2shared.com or mediafire.com. StaxRip shouldn't create any files with the extension VB, this extension is used for Visual Basic source code files which are typically only few KB. It has almost the same size as the VOB file, really strange issue.

Ajax_Undone

28th June 2008, 22:51

StaxRip shouldn't create any files with the extension VB, this extension is used for Visual Basic source code files which are typically only few KB. It has almost the same size as the VOB file, really strange issue.

Thats what I figured

I will upload later tonight am to busy right now...

*Edit* LOL Ok it was my fault I put the other VOB file into the same directory as 1.vob opon moving it I must have accidentally Deleted the O from VOB...

So 2.vb is really 2.vob...

Any how thanx for caring... But I figured it out while trying to find the 2nd vob...

weaver4

29th June 2008, 13:57

I am getting an error dialog saying "mp4 muxing failed". But I look the movie and it looks complete. Here is the log file:

------------------------------------------------------------
Muxing
------------------------------------------------------------

"C:\Documents and Settings\Trey Weaver\Local Settings\Application Data\StaxRip\Applications\MP4Box\MP4Box.exe" -fps 23.976 -add "D:\aa-Rips\MainMovie\mymovie\VIDEO_TS\mymovie.zsxq24-ipt_EncoderOutput.264:name=Video" -add "D:\aa-Rips\MainMovie\mymovie\VIDEO_TS\VTS_01_1 01 en-English 3_2ch 384Kbps DELAY -43ms_AudioOutput_AudioOutput.mp4:lang=eng:name=English" -add "D:\aa-Rips\MainMovie\mymovie\VIDEO_TS\VTS_01_1.idx#1" -new "J:\Movies\Movies-iPod\mymovie.zsxq24-ipt.mp4"

AVC-H264 import - frame size 320 x 128 at 23.976 FPS

Import results: 144464 samples - Slices: 1400 I 64324 P 78740 B - 1 SEI - 1293 IDR
Stream uses B-slice references - max frame delay 2
IsoMedia import - track ID 1 - Audio (SR 48000 - 2 channels)

VobSub import - subpicture stream 'eng'

Saving J:\Movies\Movies-iPod\mymovie.zsxq24-ipt.mp4: 0.500 secs Interleaving

------------------------------------------------------------
Muxing Statistics
------------------------------------------------------------

Start: 3:09:20 AM
End: 3:10:48 AM
Duration: 00:01:28
Speed: 1642 fps

------------------------------------------------------------
Error
------------------------------------------------------------

mp4 muxing failed

stax76

29th June 2008, 14:46

@Ajax_Undone

VOB files should better have the original filename like it's stored on the DVD (VTS_0?_?.VOB), applications can then check if there is corresponding IFO file and enable extra features with information taken from the IFO file.

@weaver4

What looks most suspiciously here is '*_AudioOutput_AudioOutput.mp4', with a common workflow StaxRip should not create such a filename. Did you do anything special?

weaver4

29th June 2008, 19:00

@weaver4

What looks most suspiciously here is '*_AudioOutput_AudioOutput.mp4', with a common workflow StaxRip should not create such a filename. Did you do anything special?

The only special thing I did was use a Template that I made.

But I looked and there was already a filed called: VTS_01_1 01 en-English 3_2ch 384Kbps DELAY -43ms_AudioOutput.mp4 in the directory that was made a few months ago.

The files do play properly.

Danisan

30th June 2008, 12:17

Hi!

I edited the filter profiles and added a new line under "[Misc]"

ColorMatrix = ColorMatrix(hints=true)

When I add ColorMatrix and use it under filters it always crashes when i proceed to the next step. It doesn't matter if I add it before loading a source or after. What am I doing wrong?

stax76

30th June 2008, 14:56

@weaver4

Did it happen only once or does it happen all the time?

@Danisan

Please try a new beta and post the error message if there is any.

Danisan

30th June 2008, 17:57

@Danisan

Please try a new beta and post the error message if there is any.

Tried the new beta, doesn't crash anymore. :thanks:

Ajax_Undone

3rd July 2008, 21:39

@Ajax_Undone

VOB files should better have the original filename like it's stored on the DVD (VTS_0?_?.VOB), applications can then check if there is corresponding IFO file and enable extra features with information taken from the IFO file.

Its all good 1.vob and 2.vob are to different Videos I was not going to merge them... Any how Happy day:)

RickA

7th July 2008, 17:44

Greets Stax,

Great program you have here! I am sorry that I overlooked it some months ago. Thanks for your work on this. :-)

Cheers,
Rick

weaver4

7th July 2008, 18:12

@weaver4

Did it happen only once or does it happen all the time?

It happens all the time. Every single mp4 encode.

stax76

7th July 2008, 18:25

@RickA

Thanks for the words of appreciation.

It happens all the time. Every single mp4 encode.

Please upload diagnostic files (http://forum.doom9.org/showthread.php?t=139212) generated by the latest beta (http://planetdvb.net/staxrip/download), I should be able to find the problem then.

weaver4

9th July 2008, 02:15

Here is the diagnostic files.

http://www.mediafire.com/?xjwnjtcpmlx

BTW: I am muxing to a remotely mapped drive if that makes any difference.

stax76

9th July 2008, 16:46

@weaver4

The audio source file is a mp3 file but the source is a DVD, did you create the MP3 source file manually in the audio settings dialog (you don't have to do this) or is it from a previous project? It would be better to select the original AC3 file as audio source file.

This does not explain the error though, it could be because it is a network drive or because the target filename has a dot, MP4Box might have problems with such things, maybe you can test things with a small sample clip. You said even with the error the output file looks OK?

What I find a bit unusual is the high audio bitrate of 174.40 kbps in relation to the small image size of 640x272.

weaver4

9th July 2008, 22:29

Interesting. Generally I make a DivX/MP3 avi file first. Then I go in and select the *.d2v file as the input to make a H264/AAC mp4 movie. Never noticed that it picked up the *.mp3 file that was made for the avi file for the audio.

I will try the other things you mentioned. and get back to you.

weaver4

10th July 2008, 03:02

I tried it by removing the period, no effect. But when I muxed to a local drive it worked fine, so the problem happens when it is a networked mapped drive.

The files are OK, but I get this error. Do you do anything to the file after the file is muxed, like set permissions?

weaver4

10th July 2008, 03:05

BTW: When you do a Divx file first and have a mp3 file in the folder. Then you try to do a mp4 with a aac file Staxrip will select the the mp3 file that is already in the folder not the ac3 file for the audio input file. This will happen even if you select new vob file and have them indexed so that a new ac3 file is generated. This is bad.

stax76

10th July 2008, 08:31

Do you do anything to the file after the file is muxed, like set permissions?

No, the error StaxRip issues should be due to MP4Box returning a error code so it should be a MP4Box issue. Somebody would have to report this to MP4Box but I'm not sure there is great support. One of the reasons why MKV is so sucessful is the author of mkvmerge provides great support here at doom9, mkvmerge is much more robust than MP4Box.

This will happen even if you select new vob file and have them indexed so that a new ac3 file is generated. This is bad.

It depends, there might be situations were MP3 is prefered but this behavior is customizable since it depends on the input types in the audio settings. Unless you don't open other vob files you can just reopen the d2v file or even better a project file.

stax76

10th July 2008, 10:57

1.1.1.0 (2008-07-10)

* Added support for custom source PAR
* Many fixes and Improvements regarding various source formats
* Many minor fixes and improvements
* x264 updated to 900
* DGAVCDec updated to 1.0.0a26
* Some new MKV features added
* Tooltip added to tray icon showing console output
* Preparers can define which formats to be used and which not
* Various aspect ratio fixes and improvements
* VirtualDub updated to 1.8.1
* Pass through encoder improved to handle not only previously encoded project but also source files
* Since the pass through encoder was improved StaxRip can now be used to (batch) remux source files
* MediaInfo updated to version 0.7.7.2, it fixes reading aspect ratio from anamorphic avi source files
* Some fixes and improvements picking up audio files
* Added MP4 demuxing, improved MKV demuxing
* Added support for more then one IDX (vobsub) file
* Added support to reorder IDX (vobsub) subtitles
* Various setup fixes and improvements
* Many useful directories added to the main menu
* A couple of improved tooltips
* Fixed two bugs with adding jobs from a second StaxRip instance
* New command to play a sound file

weaver4

10th July 2008, 15:06

But my iPod will not play MKV.

What I do is that I have two Templates one for DivX/MP3 CQ 4.0 and one for H264/AAC CRF 24. When I encode the movie with the DivX Template then I select the H264 Template and select a d2v (or vob) file. Even though the H264 Template uses AAC for audio it loads the mp3 file instead of the ac3 file.

stax76

10th July 2008, 17:33

I've added support for CRF values using decimal numbers, unfortunately it was too difficult to add migration code, all CRF values were reset to 22.

Even though the H264 Template uses AAC for audio it loads the mp3 file instead of the ac3 file.

In the audio settings under 'Input' delete 'mp3', it should then detect the AC3 file instead.

PS: I've reported the MP4Box bug to the MP4Box author.

weaver4

11th July 2008, 14:32

I was playing with RipBot264 since they also use MP4box. But with RipBot264 I do not get the error...very strange. Here is the mp4box command line from RipBot264.

"C:\Tools\RipBot\tools\mp4box\mp4box.exe" -tmp "E:\temp\RipBot264temp" -add "E:\temp\RipBot264temp\video.264" -fps 23.976 -add "E:\temp\RipBot264temp\audio.aac" -mpeg4 -new "J:\Movies\Movies-H264\My Movie--zrbq22-pch.mp4"

stax76

11th July 2008, 15:05

And if you use the RipBot MP4Box version with StaxRip?

weaver4

11th July 2008, 21:14

Nope, I will give that a try.

bmnot

13th July 2008, 21:12

I've noticed a lot of overcropping with v1.1.1.0, especially horizontal. It crops movies even if they don't have any black borders and dimensions are mod 16. Any reasons for that?

Also, when I save a new template and set it as default, it keeps nagging me to "upgrade" to Staxrip's default values. (I prefer user-defined filesize and mp4.)

stax76

13th July 2008, 21:45

I've noticed a lot of overcropping with v1.1.1.0, especially horizontal. It crops movies even if they don't have any black borders and dimensions are mod 16. Any reasons for that?

In the options there is a output mod value, by default it's 16, since there is no resize filter overcropping is necessary to achieve the output mod. Alternative would be to lower the output mod value or to resize to get a mod 16 output size, pressing Ctrl key while using the slider you can also resize keeping the source PAR which is signaled automatically then. These things are a bit difficult to understand so you might have to explain more detailed how exactly you expect StaxRip to work so I can tell you what options you need to change.

Also, when I save a new template and set it as default, it keeps nagging me to "upgrade" to Staxrip's default values.

I don't understand, what exactly does the message tell and when does the message appear?

RickA

20th July 2008, 18:24

Wanted to offer up some kudos to you Stax.

Really like the fact you made it so one can select different parameters for the encode process - especially Bitrate by Percent. I enjoy being able to quickly, easily and accurately decide on the bitrate, filesize and quality percentage I desire the output to be. For instance, with just a few mouse clicks I can see the potential outcome of 70% quality versus 90% and how they would affect filesize and bitrate.

Yes, I frequently use a much higher % than you recommend and probably what many users use. I am sure it may probably be overkill. Yet, for the little bit extra in MB to the filesize plus a nice bitrate boost. I find the level of detail (skin, hair, fine details) in the picture to be much better with a higher % - which is worth it to me. My goal is to 'archive' DVD's for a HTPC setup. So, for example, if going from 470MB to just 520MB nets me a near 100% Q versus 70ish% for an episode I will rewatch many times. I'll gladly do that. If I get about half the source filesize, full resolution and near transparent quality I am quite happy. :-)

The Crop window is super easy to use. The Preview window showing how the video would look with selected filters is an awesome bonus. I like that you show the source fps - helpfull to know when to de-interlace, IVTC, or just leave progessive.

As you can tell I am pleased with that you have created. Look forward to using StaxRip to expand my HTPC and to the improvements you may make to StaxRip in the future.

Cheers,
Rick

RunningSkittle

20th July 2008, 18:26

stax please update to the latest dgindex, 1.5.1.

thanks!!!

@rickA, have you tried out the CRF (try crf 20)option instead of shooting for a specific bitrate? Im quite sure that you will be much happier!

Poopoo

1st August 2008, 13:27

I think is had become abandonware. The slowly removing of the support forums already made clear Stax intensions.

Oh well, it was great as long as it lasted.

burfadel

1st August 2008, 13:39

I don't think stax actually wants to abandon the programme, just that development for one person takes a lot of time so I understand if he doesn't want to spend all his time on it! The source code is available, I'm sure if there are people willing to help him with its continued development that he'd graciously allow them to, and it doesn't mean he has to stop developing it himself but it would be good for both users and stax if there were people willing to do as such. Maybe a good avisynth script editor built in would get more people using it, allowing for more customisation of scripts. In any case, its is my preferred editor/encoder, so I hope its still continued!