I'm trying to open 21 files in a segmented order but the mine and feos' method has failed.
My method was the manual method of putting AviSource one after the other and feos' way was the AppendSegment method.
Both methods kinda worked but it got to the 2nd clip and stopped half way.
I did a change from opening 21 to just 5 that didn't work then 3 and that didn't work and 2 didn't even show the full clip of 2.
Edit: I was using HybridEncodeScript and apparently that "broke" it, I just did one with just AVISource spam and nothing else and it did the entire thing.
Note: I've done the mkvmerge method before for this 8 hour TAS and the audio will and I'm not joking break about 2 hours in (Audio reached 2gb). Anything related to using mkvmerge will be ignored unless it's manages to have a way to get audio to a low size.
Tried AVISource(file1, file2, ...) ?
Also, tried updating MKVtoolnix? mkvmerge just joins the streams, it doesn't do anything else with them.
Also, try CRF 16 or even 20, it should be visually very close to the original but much smaller.
I think a 65 MB file is pretty small already, lol. Especially with the upload speed he has. I rather send lossless H.264 at that rate. May give slightly better quality on YT!
Well, it'd still be 11 minutes of uploading for me. He also might want to upload longer clips later.
Aktan wrote:
Since I didn't know x264 doesn't come with MP4 muxer anymore
x264.exe didn't like me outputting an mp4 :/. Also I got a couple warnings when I changed the output to an AVI, not sure what they're about.
<img>http://i.imgur.com/FPBQdtk.png</img>
This gave me a 65MB file that can't be rendered.
The first line means that you're using a certain level but the number of macroblocks (16x16 pixel areas) surpasses the macroblock limit of that level. The second warning basically is the consequence of that: the number of macroblocks coming in per second is larger than the limit.
As for rendering... try mplayer (e.g. with a frontend like smplayer).
Btw. I'm not sure why you'd use the "TV" range for input and output - the input is definitely full range (0..255 for each RGB channel) since you're using an emulator (they always output full-range in RGB colorspace), and I'd assume that most digital TVs can already convert full-range video on their own if needed...
Also, try CRF 16 or even 20, it should be visually very close to the original but much smaller.
according to YT itself the average bitrate is 7.6kB/frame (9'568'905 bytes for 1232 frames) which I'm presuming is about 228kB/s (for 30fps video). That's with max settings though (quality = 720p) and including booting splashscreens and whatnot.
If you don't have the file you uploaded anymore, just dump ca. one minute or so again and encode it. Ignore the audio for now; you can encode that at 192kbit/s and it'll sound fine, especially with older consoles. Btw. kbits (x * 1000 bits per second) is the commonly used unit for both video and audio.
TimpZ wrote:
EDIT: I realise that it's much much lower than the 6.6MB/frame (with audio) average for the file on my computer but the entire point of the project requires that I upload with the least amount of quality loss possible on YT.
Size doesn't always imply quality. Converting video to h.264 etc. is a fairly complex process, and you can influence it in many ways. The usual ones are preset (from "ultrafast" to "placebo" == how much time you want the computer to spend finding a good encoding solution) and the choice between bitrate mode (you select an upper bound on the data rate; the preset determines how close to the original the result will look) or CRF mode (you select the quality and the preset determines how good the compression (i.e. how small the file) will be). I use x264vfw for that.
Experienced encoders will most likely use CRF mode with a quality setting adapted to the source and with an encoding time they're willing to spend; sometimes that can go to a few gigabytes for the final file and an encoding framerate in the single-digit range, so things like multithreading become very important...
TimpZ wrote:
EDIT2: Btw does "AssumeSampleRate(AudioRate / 2)" change the frequency of the audio as well as the tempo? YT 2x speed doesn't effect the frequency so if it does it would make Sonic sound groovy.
http://avisynth.nl/index.php/AssumeSampleRate
It changes the frequency, i.e. the speed at which the soundcard plays the data. Imagine a vinyl record that spins at half the usual speed.
What bitrate did your video have? (If you don't know, take the file size (without audio) in bits and divide it by the length in seconds and then by 1000 - that's your kbits/s value. Or open it up in a video player, e.g. MPC-HC, and look at the file info.)
PS: it's spelled Lararith :)
I uploaded an AVI straight from virtualdub with the settings from your previous post and it turned out like this which I'm not entirely happy with.
I could try increasing the resolution but I'm wondering if Youtube's encoder is to blame for the loss of quality or if something else could be done. I'll try the convert-command you posted though.
What exactly is wrong with it?
TimpZ wrote:
There's one last thing I'd like to try out and that is slowing the framerate to 30fps (while keeping the number of frames intact) and slowing down the audio a similar amount so you can have 60fps video using the 2x speed option on youtube. Is there a script for that? Would you recommend slowing the audio in something like audacity or can that be done with scripts as well?
I haven't tried it yet but for regular uploads on YT would it be smarter to dump AVIs using frameskip 1? Assuming that gives a native 30fps framerate on the video.
Not every console/emulator uses/dumps exactly 60fps. You can add "info" to the Avisynth script to see the exact frame rate.
Dumping 60fps is still useful if you want to TASBlend / Deblink, but there's no reason to upload more than 30fps to YT (not discounting your "2x speed option" which I haven't tested.)
An option where the user can enter a rotation angle and length, and it generates an icon somewhere between and that changes color (rotation=hue, saturation=length) accordingly?
Maybe you could tell byuu/ilari/etc. about the lag frames, maybe they'll have an idea when to insert them.
I'm also not sure if byuu has made accuracy improvements since ilari forked the code.
Open a CLI (command line interface) window; e.g. for Windows press Win+R and enter "cmd" (without the quotes).
Use "cd .." and "cd <directory name>" to navigate to the emulator. "dir" ("ls" in Unix) shows the content of the current directory. "<command> /?" shows the help text for that command. Enter the first characters of a file or directory and use the Tab key to activate the autocomplete function.
When you're in the directory of the emulator, use "mame <game name> -aviwrite output.avi".
Now then, what does this mean for the TAS?
It means I'm gonna have a fun time blowing my ears out trying to get solid RNG while maintaining some kind of respectable pathing/timing through this damn place.
Maybe you (or someone else) can find a RAM address that indicates if the game will glitch out, and display it on screen.
and 
that changes color (rotation=hue, saturation=length) accordingly?
