StaxRip x86 (development for x86 has been stopped)

[Havokdan]

@Havokdan

So the temp dir was ending with 'temp files' and it wasn't deleted even though the option was enabled, the log file was in the target dir?

Let's see, when the temporary folder in the hd is my operating system (Unit "E") they are not deleted after the end of the operation, even if this option is checked and the log in the temporary folder in this case.
Even when I set the temporary folder to "C" drive (NTFS - empty, no operating system), the folders are deleted and the log goes to target dir as you said.
For me this is no problem, but I found this strange behavior.

[MuLTiTaSK]

@stax76

i been running different projects and the errors seem to be related to DGIndexNV cause i havent been able to duplicate it with any of the other indexers hope that helps

[Desaster Dan]

@multitask
did a 2 pass coding last night, with the x264_64 workarround.

The result looks this way:


To crosscheck i muxxed the compcheck.h264 into mkv this morning.
This one looks normal.
what's that?

@Stax
Maybe it is a good idea to stick native x264_64 support inside Staxrip.

[Maeggor]

Hi people

I have used this fantastic program in XP without problems but I have update my system to Win7 x64 and the 1.1.3 doesnt initiate when I click it

Any ideas or you have the similar problem¿

Thanks!

[MuLTiTaSK]

@Desaster Dan

please post the .log for that project

[MuLTiTaSK]

@Maeggor

where you using any other version before 1.1.3 on Win7 x64?

[Maeggor]

Originally Posted by MuLTiTaSK

@Maeggor

where you using any other version before 1.1.3 on Win7 x64?

I dont know what you mean!

In the same computer (with the same hardware but only adding a SSD) and with Windows XP 32bits, and 1.1 Staxrip version!

[MuLTiTaSK]

@Maeggor

download this .NET Version Detector copy and paste the results here

[stax76]

Maybe it is a good idea to stick native x264_64 support inside Staxrip.

StaxRip wouldn't do anything different than what the workaround does. I don't have x64 so couldn't test it. Such issues are exactly the reason why it's not supported directly, higher potential for hard to track bugs, same issue with patched x264 builds.

i been running different projects and the errors seem to be related to DGIndexNV cause i havent been able to duplicate it with any of the other indexers hope that helps

The error handling was intended to be improved so if the source fails to load it will automatically try ffms2 without blocking which is useful for batch processing. There was a bug however causing this not working correctly not even showing a message about the error but only write it to the log file which finally gave me a idea what was happening. It applies to most errors, not only dgi.

@Havokdan

so was the temp dir ending with 'temp files', only then it gets deleted and using the file browser instead of manually entering always results in a 'temp files' ending.

[Zathor]

Originally Posted by MuLTiTaSK

with this workaround i'am noticing a speed increase of about 8% a very nice boost
maybe you can add a option for the user to choose what build to use x86 or x64 depending on there cpu then have StaxRip avs4x264.exe->x264.exe(x86) or avs4x264.exe->x264_64.exe(x64)

You have to use vfw4x264.exe instead of avs4x264.exe. If you use avs4x264.exe some videos look like the one from Desaster Dan. I can reproduce it with mpeg2 videos with DGDecode_mpeg2source. There is no know problem with vfw4x264 and even with the new x264 1391 build with no vfw input support (removed since 1379) it is still working.

[MuLTiTaSK]

@Zathor

i was just able to reproduce this

[Desaster Dan]

@Multitask

Here we go:
Stream Type: Program
Video Type: MPEG2
Profile: main@main
Coded Size: 720x576
Display Size: [not specified]
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Colorimetry: BT.470-2 B,G*
Frame Structure: Frame
Frame Type: I
Coded Number: 179174
Playback Number: 179174
Frame Repeats: 0
Field Repeats: 0
Bitrate: 5.672
Bitrate (Avg): 4.883
Bitrate (Max): 7.428
Audio Stream: 80: AC3 3/2 48 448
Audio Stream: 81: AC3 3/2 48 448
Audio Stream: 83: AC3 1/0 48 192
Audio Stream: 8a: DTS C+L+R+SL+SR 48 768
Elapsed: 0:04:31
Remain: 0:00:00
FPS:
Info: Finished!

Oops, too late ;o)

[MuLTiTaSK]

@Desaster Dan

vfw4x264.exe->x264.exe

[stax76]

@MuLTiTaSK

Do you have experience with MakeMKV? I'm ripping some Tom Cruise Nazi Film right now, first Blu-ray rip. I don't have AnyHD.

[MuLTiTaSK]

@StaxRip Nation

to use x64 builds of x264 in StaxRip follow this very simple workaround

1)download x264x64 Wrapper by alwa
2)rename vfw4x264.exe->x264.exe then place it in x264 folder

3)download x64 build of x264 from your favorite builder
4)rename build to x264_64.exe then place it in x264 folder as in step 2
DONE!

[MuLTiTaSK]

@stax76

welcome to the world of Blu-ray
Inglourious Basterds is a funny flick you having troubles with MakeMKV?

[Desaster Dan]

@multitask

Thank you,
It's running like hell now on My Gforce 9600
~95 fps on first pass
~25 fps on second pass.

[MuLTiTaSK]

@Desaster Dan

nice speeds x264x64 builds give a nice boost

[MuLTiTaSK]

@stax76

you using MakeMKV 1.4.11

[MuLTiTaSK]

@stax76

Download latest MakeMKV combined SVQ file for BD+

Usage
In order to use SVQ file just download it into "SVQ directory" set in MakeMKV preferences (on BD+ tab). MakeMKV will automatically pick-up the SVQ file and all discs that are enabled in SVQ file will start working. You must set "SVQ directory" in preferences, but you need to do it only once.