windows i'm assuming?
Windows 7, 64 bit, Core i7-2720QM processor. I estimate Anri is 3x faster.
SDA Forum
Edit history:
UraniumAnchor: 2014-04-01 08:24:26 pm
UraniumAnchor: 2014-04-01 08:23:43 pm
UraniumAnchor: 2014-04-01 08:23:03 pm
Not a walrus
NES should indeed be 30.whatever, but DVDs already ruin that, but they do it in a way that doesn't actually matter, since they just drop frames and the timing remains intact, as far as I know. Using DVD footage to sync up *GDQ videos shows the actual drift is incredibly minor (the worst I've seen is <10 frames over the course of an hour). Granted, if you have a shitty DVD recorder, that might not be true, but all bets are off at that point.
so i timed yua and anri on my old phenom ii x6 (2.7 ghz) desktop. it runs xp (fully updated). i rebooted before each test to make sure there was no caching going on.
input was a ~84 minute long interlaced 640x480 29.97 fps yuy2 lagarith avi with stereo mp3 (128 kbit) for the audio. it's a bunch of tmnt3 (nes) attempts. i encoded d4 f1 2d lq/mq/hq without statid (and without saying yes to the nes question in anri or checking downmix to mono since crow probably wasn't doing that). d4 filter was no change.
hq was 1 pass and mq/lq were 2 passes for both anri and yua.
yua seems to do better than anri on the lq and gets creamed on the mq. it's possible that yua's mq x264 settings are different. i tried to emulate anri closely but i may have updated some settings for modern times. also the version of x264 is probably like ... 3-4 years newer in yua. so it's possible that x264 got more hardcore in that time with the same settings.
just because i was curious, i tried recompiling yua to totally disable the preview while encoding. unfortunately my static qt 4.8 windows build is broken, so i had to compile dynamic with qt 5.2.1, and somehow large file support in ffmpeg broke. so this yua could only encode the first 4 gigs of the input. however i extrapolated based on how long it took to do that much and got ~70 minutes to do the hq (again single pass) and ~267 minutes to do everything, which is just slightly longer than the normal yua. so my guess that the preview is irrelevant is probably correct, at least on this hardware.
anyway, if anri is a lot faster for you then you're welcome to use anri. i think it probably depends on a lot of things.
one last thing. interlaced d1 encoding will be very different in yua versus anri. it may be much slower or much faster, and it also depends on whether you say yes to the nmf question in anri. finally, it also depends on the output quality. for example, in the case of interlaced d1 stuff, mq will always be much faster in anri.
input was a ~84 minute long interlaced 640x480 29.97 fps yuy2 lagarith avi with stereo mp3 (128 kbit) for the audio. it's a bunch of tmnt3 (nes) attempts. i encoded d4 f1 2d lq/mq/hq without statid (and without saying yes to the nes question in anri or checking downmix to mono since crow probably wasn't doing that). d4 filter was no change.
Code:
anri yua lq 88m 68m mq 91m 137m hq 44m 58m sum 223m 263m diff ~15.2%
hq was 1 pass and mq/lq were 2 passes for both anri and yua.
yua seems to do better than anri on the lq and gets creamed on the mq. it's possible that yua's mq x264 settings are different. i tried to emulate anri closely but i may have updated some settings for modern times. also the version of x264 is probably like ... 3-4 years newer in yua. so it's possible that x264 got more hardcore in that time with the same settings.
just because i was curious, i tried recompiling yua to totally disable the preview while encoding. unfortunately my static qt 4.8 windows build is broken, so i had to compile dynamic with qt 5.2.1, and somehow large file support in ffmpeg broke. so this yua could only encode the first 4 gigs of the input. however i extrapolated based on how long it took to do that much and got ~70 minutes to do the hq (again single pass) and ~267 minutes to do everything, which is just slightly longer than the normal yua. so my guess that the preview is irrelevant is probably correct, at least on this hardware.
anyway, if anri is a lot faster for you then you're welcome to use anri. i think it probably depends on a lot of things.
one last thing. interlaced d1 encoding will be very different in yua versus anri. it may be much slower or much faster, and it also depends on whether you say yes to the nmf question in anri. finally, it also depends on the output quality. for example, in the case of interlaced d1 stuff, mq will always be much faster in anri.
Hi, I'm having a weird problem. I had no problem processing some quality tests samples and now I'm trying to process the entire run and Yua just doesnt create any file after it is finished... It took me 7 hours to process a 20 minute video on lq,mq and hq. I chose Desktop as the file output but nothing is there... Any idea? (The run was recorded with amarectv and I had to fixe progressive audio desync with Virtualdubmod. The file is .avi 640x480 29fps. before processing I chose interlaced, top field first, standard, D1, F2, 3D. Quality test: https://forum.speeddemosarchive.com/post/quality_test__sonic_r_gc.html
The Dork Knight himself.
Try this: do another encode but do NOT use spaces in the filename. For testing reasons, only grab a smaller section of the source video (use the Trim menu for that). I ran into this before and it seems if you have spaces in the filename it tends to not save the video after encoding.
sinister1
so pro u don't even know
Quote from nate:
can you upload it?
See attached. All I did was open Yua.exe and then File > Open > (.vob file Anri ripped from my DVD). Let me know if there is more I am supposed to do there. I could just be super dumb and missed an obvious step. Thanks.
Attachment:
You guys need to actually test this stuff. It's not the %, it's the colon. Try renaming a file in windows, as soon as you attempt a ":" it gives an error, so of course you won't be able to output a file like that.
nate, as Onin said above:
In Windows, should be: \ / : * " < > |
nate, as Onin said above:
Quote from Onin:
Might be useful for Yua to detect unaccepted characters in filenames to prevent this happening in the future.
In Windows, should be: \ / : * " < > |