The zlib dll file in "fceu-0-98-12-avifix.7z" is mislabeled "libz-1.dlll" (note the three "l"s as opposed to the intended two in "dll") and is missing from the "fceu-0-98-16-avifix.7z" archive.
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 240p, 480p, 720p, 960p
Compatibility MP4: 240p, 480p, 720p, 960p
Torrents:
10bit444 MKV: 240p, 480p, 720p, 960p
Compatibility MP4: 240p, 480p, 720p, 960p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 244p, 488p, 732p, 976p
Compatibility MP4: 244p, 488p, 732p, 976p
Torrents:
10bit444 MKV: 244p, 488p, 732p, 976p
Compatibility MP4: 244p, 488p, 732p, 976p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
That makes sense.
My initial problem was that I wasn't sure if it enabling the overscan was an emulator-specific option, for instance if it was something artificial generated to help with the aspect ratio correction but not present on the actual console.
Given all the information provided here, I'd also vote to keep the overscan in the encodes.
I'm not as active as I once was, but I can be reached here if I should be needed.
Are the numbers you end up using for ARC equal to these?
The numbers that end up being used for the correction are as follows:
4 * 284 / 256 * 10000 = 44375
3 * 244 / 192 * 10000 - 38125
Simplified, that would be 71 and 61.
That, applied to the cropped width and height yields an AR of 18176:11712 (or simplified, 284:183).
284/183 = 1.56043956044
16/10.5 = 1.52380952381
So back to the original question, I'd say yes. This was also compared for accuracy to the clip with overscan being resized to 4:3 and then cropped down. It looks like 284/183 is the "something around 16:10.5" that you were thinking of.
I'm not as active as I once was, but I can be reached here if I should be needed.
I haven't heard of Avidub sorry, unless you meant "is it an AVISynth script, which can be viewed in Virtualdub?" in which case, yes. It is an AVISynth script.
Be sure to swap out "movie_a.avi" and "movie_b.avi" with actual dump files!
I'm not as active as I once was, but I can be reached here if I should be needed.
# Load Source
Clip1 = AVISource("movie_a.avi")
Clip2 = AVISource("movie_b.avi")
# Apply any trim necessary: first value is the starting frame, second value is the ending frame
Clip1 = Clip1.Trim(0,0)
Clip2 = Clip2.Trim(0,0)
# Set the number you want the frame count to start from
initial_frame_clip1 = 0
initial_frame_clip2 = initial_frame_clip1
# Stack the output clips and draw subtitles (this is automatic and does not need to be changed)
prefix = "Frame: "
Clip1 = StackVertical(Clip1.BlankClip(color=$000C47).Crop(0,0,0,-(Clip1.Height-56)), Clip1).ShowTime(size=18, text_color=color_white, y=20).ScriptClip("subtitle(prefix + string(current_frame + initial_frame_clip1), size=18, text_color=color_white, align=8, y=28)")
Clip2 = StackVertical(Clip2.BlankClip(color=$470000).Crop(0,0,0,-(Clip2.Height-56)), Clip2).ShowTime(size=18, text_color=color_white, y=20).ScriptClip("subtitle(prefix + string(current_frame + initial_frame_clip2), size=18, text_color=color_white, align=8, y=28)")
StackHorizontal(Clip1, Clip2)
Subtitle("A", align=8, size=48, text_color=color_white, halo_color=color_blue, x=(last.width/2)-35, y=2)
Subtitle("A", align=8, size=48, text_color=color_white, halo_color=color_blue, x=35, y=2)
Subtitle("B", align=8, size=48, text_color=color_white, halo_color=color_red, x=(last.width/2)+35, y=2)
Subtitle("B", align=8, size=48, text_color=color_white, halo_color=color_red, x=last.width-35, y=2)
The result is rather nice and it's fairly customizable.
[/img]
I'm not as active as I once was, but I can be reached here if I should be needed.
About a year ago, Sega Master System dumping changed to include overscan. This allows much more accurate aspect ratio correction at the cost of black borders around the entire game.
I messed around and made a commented AVISynth script that takes the aspect ratio of the clip with overscan enabled, crops the clip to what it would be were the option not enabled, and then applies the aspect ratio to the resulting clip. This results in a clean clip with the same aspect ratio correction as if the clip did not have the overscan removed. It's worth noting that this means the resulting clip is not 4:3, but is instead displayed with an accurate aspect ratio, although without the overscan being visible.
You can download test file and script here, the file's about 4mb. Alternatively, here's the script by itself:
I'm not experienced enough with the console to know if cropping is consistent between games (although it can easily be checked and altered) or if the encodes would be preferred with the overscan included, as I'm not sure which is correct in terms of console accuracy, but if aspect ratio is the only contributing factor to enabling the overscan setting, then this might help deal with that.
Edit: Originally, there was an extra line (line 18) left in the script's download and in the code pasted here. It was commented out, but still present. I used it for testing and it should not be used in the final script as it extended the cropping beyond what was needed to crop the overscan. It has since been removed from both locations.
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
Torrents:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
Torrents:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 240p, 480p, 720p, 960p
Compatibility MP4: 240p, 480p, 720p, 960p
Torrents:
10bit444 MKV: 240p, 480p, 720p, 960p
Compatibility MP4: 240p, 480p, 720p, 960p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 240p, 480p, 720p, 960p
Compatibility MP4: 240p, 480p, 720p, 960p
Torrents:
10bit444 MKV: 240p, 480p, 720p, 960p
Compatibility MP4: 240p, 480p, 720p, 960p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x:
10bit444 MKV: 432p, 864p
Compatibility MP4: 432p, 864p
To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
Torrents:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
Torrents:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
When are the first two drops in relation to the segments? are they near the end of one / start of the next, do they plague certain resolutions or are they simply scattered about?
I'm not as active as I once was, but I can be reached here if I should be needed.
Aktan and I had a long talk in IRC and did some thorough tests of the different methods regarding loading Dolphin sources. I'll try and cover everything in this post as best I can. If you just want the conclusions drawn from these tests, they will be at the bottom of this post, otherwise here are the test files.
The first thing to note is that a lot of the conversions have already been done. Most of the remaining batch files and scripts are present to show exactly what was done in order to get these output files prepared. I'll go over that first. If you want to do these tests in their entirety yourself (and not use the pre-prepared files), start at step 1. If you just want to compare the pre-prepared files, skip straight to step 7.
1 - Delete the contents of the "lagarith_output" folder, and the contents of the "dumps" folder, with the exception of framedump0.avi and dspdump.wav. These two files are dumps done with Dolphin 5.0's release and were the dumps used for testing. These can be replaced with your own Dolphin dumps if necessary, provided they overwrite the original files.
2 - Running the batch file "make-ffmpeg-ffv1" will create a new file in "dumps" using the FFV1 codec. The point of this conversion is to change some of the codec settings and correct the colorspace into something AVISynth will accept.
3 - Running the batch file "make-ffmpeg-x264rgb" will create a new file in "dumps" using the x264rgb codec.
4 - Now that the dump files are prepared, source loading can begin. Load "load_dolphin_ffms2.avs" in Virtualdub. The application may appear to have frozen - this is normal. The bigger the dump, the longer this process will take.
5 - Once you see the video has loaded, quit out of the program. Load "load_dolphin_lsmash.avs" in Virtualdub. Once you see the video has loaded, quit out of the program. The reason behind doing this (and the previous) step is that these source filters create index files. In certain circumstances (particularly with LSMASH) on the first load (the one that creates the index), the video output will be incorrect, having absent frames and incorrect timings.
6 - Load up each of the six AVISynth scripts beginning with "load_" and save them using a lossless codec (I recommend Lagarith) to the Lagarith output directory using their default file names. If "load_ffmpeg_ffv1_avisource.avs" or load_x264rgb_avisource.avs" give you any trouble or do not display the correct output, and installer for a compatible version of ffdshow has been provided in the prereq folder. Installing this should fix the problem. The files appended with "_60" have been given parameters for a forced frame rate of 60fps. You can examine the scripts as necessary.
7 - Edit "compare.avs". The first few lines load up all of the Lagarith output files created in the previous steps (or pre-prepared, if you've skipped straight to this step) and assign them various names. Method1, Method2, Method3 and Method 4 are all methods of loading up the source directly in AVISynth. Compare1 and Compare2 have been losslessly converted using FFMPEG prior to their loading and make good reference clips for this reason. Set Clip1 and Clip2 to whichever two of these you wish to compare. By default, "Clip1 = Compare1" and "Clip1 = Compare2". This compares both of the FFMPEG converted files. Save the script.
8 - Load the script in Virtualdub. The video should appear grey. You can seek through the video - any moments that aren't identical in the two clips will become visible.
9 - To ensure the clips are completely identical, set the codec to Lagarith and save the video file anywhere you can find. For this example, I'll call it "compare.avi" and it'll be saved to my desktop.
10 - Load the file you just saved in Virtualdub. Hit File > File Information. We want "Number of Keyframes:" to be 1. If it's higher, this means there was a difference between the two compared video files, potentially one too subtle to make out at first. If it is 1, ensure the keyframe is the first frame of the video. Repeat steps 7-10 for as many different comparisons as you wish to do. If the files are identical, particularly to Compare1 and Compare2 (which are identical to each other), then they have been loaded up correctly.
These tests confirmed what I originally thought: LSMASH does load the Dolphin dumps correctly when given a forced frame rate. A few other things worth mentioning are that that FFMS2 gives an incorrect result both with and without the forced rate, and that LSMASH gives an incorrect result without the forced rate. This means that as far as I can see, the best way to load Dolphin dumps without converting or re-encoding prior to AVISynth usage is using the following:
That being said, transcoding with ffmpeg to both FFV1 and x264rgb is just as accurate if you'd prefer operate with AVISource and don't mind the extra disk space usage or waiting time.
The command to convert to a readable FFV1 stream using ffmpeg is as follows:
It looks like in addition to the necessity of level 1, another big issue with the original Dolphin FFV1 dump is the colorspace being bgra. It looks like some sort of incompatibility with the alpha channel is part of the problem and as you'll see above in the ffmpeg codec for converting to FFV1, the line "-pix_fmt bgr0" fixes this. It might be worth trying to get the additional parameters ("-pix_fmt bgr0 -level 1 -g 1 -coder 1 -context 1") implemented into Dolphin directly, so in the future dumps can be loaded directly with AVISource.
Anyway, I think I've spent far too much time typing this thing up already so I'll draw the post to a close here. A lot of the technical work would not have been possible without Aktan, who was responsible for a vast majority of the problem solving, parameters and,well.. everything.
There is one outstanding problem here still, however. feos wrote:
My tests with libav and ffms2 show that it always drops or adds frames. For reliable comparison I have a cfr lossless dump that I can load normally (even though it's segmented), and then with ffmpeg and compare. With dolphin, you need some absolutely accurate source to compare to.
Post #459368
Given it's CFR, were you forcing the CFR rate? And did you let the index build and then reload the clip to ensure you were getting the correct timings?
I'm not as active as I once was, but I can be reached here if I should be needed.
@Aktan, could I have the command line for ffmpeg to do FFV1 level 1 to compare?
In my tests against the x264rgb file I created with ffmpeg I found that file loaded up with AVISource and the original dump loaded up with LWLibAVVideoSource to be identical when loaded using 60/1, although this comparison was sound, I did only thoroughly examine (frame by frame) known problem areas using FFMS2 as the dump I was using was excessive in size (250,000+ frames).
I'd like to examine this further in direct comparison to what you suggested, with the latest ffmpeg and AVISynth plugins. I'll happily provide files for these tests, too (scripts, plugins and dumps, etc) so everyone can see the results and compare them for themselves.
Also, to elaborate and clarify the problem with FFMS2 with loading Dolphin dumps outright (for anyone not aware), the issue is that it loads the clip at the incorrect rate when no parameters are specified, eg: FFVideoSource("clip.avi") - causing frame times to be off by a large amount in certain circumstances (leading to desync in audio as feos has pointed out) and potentially absent frames. When the parameters were set to 60/1, it skips and duplicates frames as necessary to achieve the target rate rate causing a lot of unnecessary stuttering and missing frames. This outlines "do not ask it to perform any framerate conversions", as natt said. The issue is that without those parameters, the rate it gives is not the correct one. When loading up using LSMASH and the same 60/1 rate, I get a completely smooth video with those frames still in tact, with no dropped frames in comparison to the ffmpeg output file I produced prior (therefore, performing how I believe it should).*
*Although as I mentioned earlier, this was done through tests I'm not thoroughly satisfied with and I'll be conducting more in the very near future.
Edit: As a second note, if LSMASH doesn't have a rate specified it works the same was FFMS2 without a rate specified, loading the crip at an incorrect rate and causing frame timing to be off. 60/1 has to be specified to properly circumvent this.
I'm not as active as I once was, but I can be reached here if I should be needed.
The biggest problem with that was related to the dump size. A 775gb dump meant it took quite a while and took up a fair bit of extra space. While that's not an issue for me personally, I was hoping to find a way to load the dumps up directly without first needing to re-encode or convert them.
What's the problem with LWLibAVVideoSource? Is there's a frame inaccuracy I didn't notice somewhere during my tests?
I'm not as active as I once was, but I can be reached here if I should be needed.
I don't think so. My understanding (which may be incorrect) is that it's tied to memory, which is in turn tied to the fact it's 32-bit.
That being said, provided it's a standard CFR situation and I've dumped using lagarith, I often load up "segment000.avi" in virtualdub, append "segment001.avi" (which appends sequentially until it stops finding numbers following the naming pattern) and then save using direct stream copy to a second single-segment file. It takes a bit of time (as it's copying the streams, it takes about as long as copying a file of whatever the size of the video is) and more HDD space, but afterwards you can delete the input files afterwards and then only have to worry about importing a single file when it comes to AVISynth.
I'm not as active as I once was, but I can be reached here if I should be needed.
This might be old or irrelevant news, but quite a while ago I mentioned FFVideoSource("movie.avi", fpsnum=60, fpsden=1) loaded Dolphin dumps incorrectly. This is still the case, as it drops several frames, best explained by ABCCEFG (in this example, "C" is duplicated and "D" is entirely absent). Using the old M/D method with calculations was my original work around this, but gives the wrong output frame rate and duplicates or deletes a frame every thousand or so. It was better than the alternative, but it's still incorrect.
The latest LSMASHSource has been updated to fix this. LWLibAVVideoSource("movie.avi", fpsnum=60, fpsden=1) loads the source correctly, giving ABCDEFG in the above situation, although it needs to load twice to be correct. The first load builds the index and loads the clip (this takes significant time, depending on the dump size and the program appears to be frozen for this duration). Virtualdub must then be quit and re-opened to give the correct frame timings and results (this only happens on the initial load, subsequent loads once the index is created are fine).
This is definitely an improvement over the alternatives mentioned above, or using ffmpeg to convert the FFV1 dumps into a more usable format.
Also, it's worth noting that due to the nature of 4K dumps and the resolution size, Virtualdub may freeze or crash during seek (or if you try and save directly from Virtualdub). Closing the program and reloading the script fixes this and the encoding package deals with this without issue.
I'm not as active as I once was, but I can be reached here if I should be needed.
I'm not sure, that's something that's definitely beyond my field of expertise. If not though, it could probably be re-organized to have a prereq installer of some sort that grabs the appropriate stuff, perhaps.
I'm not as active as I once was, but I can be reached here if I should be needed.
As far as I can tell it's all good - at least on my machines!
It's worth noting that iTunes was removed prior to the testing. Whilst I don't think think that this would affect the testing process (and removing the newly included files caused qaac to fail as expected) there could still be some interference if there were unforeseen components left over.
I'm not as active as I once was, but I can be reached here if I should be needed.
[/img]