It's not a cut, it's an addition. qaac, at least the version I currently have, which is relatively new, HE-AAC actually removes samples from the original source, so you need to add samples. It doesn't make sense since gapless playback wouldn't work at all, but maybe HE-AAC isn't meant for gapless? I have no idea.
After chatting with thecoreyburton, we found out that the delay for HE-AAC for qaac was wrong. So I went and check (almost) all the samples and found out it is missing 957 samples all the time (didn't check 1 44.1 kHz sample). I now think the param for qaac should be:
The "--no-delay" param could not be used since it only works in AAC-LC. This is a big change vs what I had before, so I'm not sure if it is due to iTunes or qaac changing it. I will list the versions of each I am using.
qaac Version 2.64
Apple Application Support (64-bit) Version 5.6
I still think there is something wrong with your test method, as opus can't be cut off samples or else gapless playback is impossible. I just did one test, and opus again added 287 samples. I'll finish the others and update this.
Edit: Okay, I've finished testing. All 44.1 kHz samples had a 287 sample delay and the only 48 kHz sample had a 312 sample delay. If you convert both to seconds, it's about 6.5 ms. So in general, I think you always need to cut off 6.5 ms.
The delays in NeroAAC is there in the very old encoding guide here:
http://tasvideos.org/EncodingGuide/PreEncoding.html
There is a difference from HE-AAC and AAC. I think this is moot though, as we should be using qaac which has different delays. For qaac, it is 2112 samples for AAC and 5186 samples for HE-AAC.
When I went through opus-tools parameters, I didn't see anything for the delay, like you said, but since I knew about the AAC delays, I could have sworn I did testing to make sure it didn't have a delay. I guess I'll revisit that. In the past, we used a square wave to easily tell when there is a delay as shown here:
http://tasvideos.org/forum/p/282143#282143
I also do use the param "--padding 0" but that's for metadata.
As for oggenc, I thought someone else did the test to see if there is a delay, or I now faintly remember there was a known delay, but as you said, too small to care.
PS: I highly recommend not using ffms2, which has terrible video syncing, (unsure in audio). At least it is consistent in being bad in video, I guess.
PPS: This may help: https://en.wikipedia.org/wiki/Gapless_playback
Edit: Well due to the notes in the Wiki link, I found the flaw in my testing. Since I used opusdec to decode the opus file, it took account the gapless support on the ogg level auto removing it. Once I mux the opus file to a MKV and then output to WAV with ffmpeg, I do indeed see a delay. I'll do more research and check what the exact delay is.
Edit 2: For my test file of 44100 kHz with ~64 kbit/s opus file, I got a audio delay of 286 samples. This is ~6ms longer than the original that must be trimmed off. So it would have been a negative delay in AviSynth, but the recommend method is use SoX to remove the exact sample amount. I'll do more test in 48 kHz.
Edit 3: Good job to thecoreyburton for noticing this!
To me all it comes down to which tradeoff is not as bad. Point + Point is sharp but the pixel sizes are inconsistent. Point + Lanczos has consistent pixel sizes but is slightly blurry. Personally, I don't like the blocky look, but since we are stuck on that, I guess I would go with Point + Lanczos. Honestly, the best way to go with Point + Lanczos IMO is:
It does if it's the only line and you're not assigning it to a variable (though at that point you may as well not be using avisynth in the first place!)
I know, you're not getting my poking fun at him =p.
Yeah, all of that works. But it's highly redundant - you already set last with a single line of "AVISynth(...)".
"return last" looks like "i = i + 1;" to a C programmer.
actually if you just do
Language: avisynth
a = AVISource("whatever.avi")
I believe last is not set and AviSynth returns an error. In your example, the shortcut is to do i += 1;, but there is no such shortcut in this case, the person reading has to "know" that last is implicit.
luma upscale 12x with point + downscale with lanczos
chroma upscale 12x with point + downscale with lanczos to half target res + upscale with point
(note: easier way to do this with taps=3 is to just subsample with lanczos though it be double lanczos downscale)
http://i.imgur.com/uPJE6YE.png
When writing functions that take a clip as their first parameter, I (almost) always put the clip variable on its own line to make it the "current" clip. So yes, it does work.
That's functions, I'm talking does this work:
Language: avisynth
a = AVISource("whatever.avi")
a
Even if it does work, this is more readable IMO:
Language: avisynth
a = AVISource("whatever.avi")
last = a
return last
Sometimes I set it since I was working on another variable and now I want it to be the main one. I actually have not tried just placing a clip variable on a line to set it to last. If that works, wow, surprised I've not thought of it. If that does indeed work, I would say explicitly having "last =" makes it more readable =).
Third - You do not need return last, since avisynth is weird and doesn't require return last if the last line of your script is a clip and isn't a variable declaration.
Actually even though it is implied to be there, AviSynth is weird in that if you start doing something like last = clip, you are require to return last. I mean it doesn't really hurt so keeping it there is it's not that big of a deal.
On the other hand, Mupen has plenty of encodingissues which makes them a very large pain to publish.
I looked at some of those encoding issues:
"Consistency is optional: Playbacks fail to sync or sync differently on different playthroughs for no apparent reason." Mupen basically never desyncs like that. It only desyncs if you load state or save state or something stupid on the first frame of the TAS.
"fails if monitor goes into powersaving mode" this only happens if aero is turned on. Just turn it off.
"captures parts of windows and menus in front of the capture window" that's annoying but can be avoided by not putting anything in front of the Mupen window.
"no 2GB split" There is an AVI-splitting version of Mupen. It Only splits 26 times (which is annoying), but it works.
You forgot other problems, like audio dropouts on longer captures, crashes with capture with 2GB split version, audio channels swapped, limited files outputed by 2 GB split before Mupen crashes due to running out of letters (it splits by adding a letter to the end of the filename, guess what happens when all 26 letters are used... yes, the capture is THAT bad) .
jlun2's suggestion of rewriting the capture part of Mupen is a sound idea, but of course, we need someone to actually do that. It is less likely for someone to work on code that will be obsoleted soon anyway...
Based on the encode:
35:30 There's a frame where link is in a perfect pose, ready to hit dead hand on frame 1
47:47 Showing off one of the coolest new tricks
53:11
1:11:55 OoB swimming with the sun being visible in the void
I 2nd Pokota's post on AVS+. It works fine as far as I know (Rolanmen1 has been using it a lot for his encodes). Only problem is getting 64-bit plugins as not all of them are recompiled to 64-bit.
I recommend using qaac instead of neroaacenc for our AAC audio.
https://github.com/nu774/qaac/releases
It uses Apple's AAC encoder so you also need to install Apple Application Support to have the right DLLs to use it.
Is it possible, without or without specified softwares, to convert the movie file from .M6 to .BK2 ? and If so, would it correct the actual problem and allow runs done on Mupen be imported in bizhawk ?
Go and hate me if you want, but I think it's a terrible idea to give exceptions for Mupen. Allow it here and the OoT and SM64 communities will never learn to move on from this awful emulator.
I'm just feeling sorry for the publishers who have to slam their heads into the desk trying to sync it, given the past history of Mupen desyncs.
I got zero desyncs, it just took around a week to capture though, lol.
