It used to be so much simpler in the past. If it wasn't for nesvideos, I never would have been the knowledgable encoder that I am right now, and I have been made aware of the new --deldup feature but it doesn't seem to be available in x264 but in other codecs.
I have figured out the Dedup avisynth plugin (which you guys have no guide on) but I can't figure out how to make my MP4 vfr. I have the timecodes and I tried tc2mp4 but then the muxed audio was out of sync and I couldn't find out why.
I understand that there are two tools authored by people on this site, NHML trasnform and NHML fixup. I have no idea how to use fixup because the post assumes I'm familiar with Lua, which I'm not. WIth NHML transform I have been getting a "bad parameter" error, first with audio in my ninja gaiden encode and then with video on dragon warrior encode.
Help would be appreciated, and please return the guides to how they were, simple and step-by-step, not the confusing and fragmented mess it is now.
Thanks.
I thought the guide was quite step by step, but I may be wrong. As for your problem with NHMLTransform, could you post what exactly you have tried, so I can see what may be wrong? Basically, tell me the exact command you tried.
I have no idea how to use fixup because the post assumes I'm familiar with Lua, which I'm not.
Here's how my encoding scripts (that I haven't used for a long time) use NHMLFixup (with a bit of adaptation):
MP4Box -nhml 1 video.mp4
MP4Box -nhml 1 sound.mp4
lua NHMLFixup-v7.lua video_track1.nhml sound_track1.nhml timings.txt tvaspect
MP4Box -add video_track1.nhml -add sound_track1.nhml -new final.mp4
Of course, one needs the Lua interpretter for that.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Santiago wrote:
I have been made aware of the new --deldup feature but it doesn't seem to be available in x264 but in other codecs.
--deldup is specific to the direct264 build of x264. It has been known to be problematic (in particular, it can remove non-duplicate frames).
Santiago wrote:
the muxed audio was out of sync and I couldn't find out why.
Out of curiosity, how was it out of sync? I know that tc2mp4 does not take into account some audio-related fixes that NHMLTransform and NHMLFixup both do.
Santiago wrote:
I understand that there are two tools authored by people on this site, NHML trasnform and NHML fixup. I have no idea how to use fixup because the post assumes I'm familiar with Lua, which I'm not.
NHMLFixup doesn't really require you to be familiar with Lua, just that you have it installed and available.
Santiago wrote:
WIth NHML transform I have been getting a "bad parameter" error, first with audio in my ninja gaiden encode and then with video on dragon warrior encode.
Speak to Aktan (as he offered above).
Santiago wrote:
please return the guides to how they were, simple and step-by-step, not the confusing and fragmented mess it is now.
Is there anything in particular, aside from the above, that is confusing? We've tried to present the guide in a fashion that helps you understand why you are doing what you are doing, and we aim for it to be as clear as possible.
I didn't change it, that is the default on the DeDup help file. You guys dont even have a guide for DeDup, but whatever, I have changed it to yours, re-encoded and tried again. I'm still getting Error importing audio2.nhml: Bad Parameter. Why?
I'm still getting Error importing audio2.nhml: Bad Parameter. Why?
audio2.nhml? How did you get filename like that? IIRC, the names MP4Box generates are of form foo_track2.nhml (I have pretty old version, so this may have changed).
If you renamed it, did you rename the other associated files (IIRC, there's 2 others, for total of 3) too (those files have important stuff in them)?
From your very own written guide which tells me to do:
MP4Box video.mp4 -nhml 1
MP4Box audio.mp4 -nhml 1
NHMLTransform.bat -i video_track1.nhml -t times.txt -o video2.nhml -ia audio_track1.nhml -oa audio2.nhml
MP4Box -add video2.nhml -add audio2.nhml -new encode.mp4
MKV is not standard, MP4 is and I follow the standard. You wouldnt hear jiggles in AAC audio if you disabled the SBR feature by adding -LC to the script. OGG should be abandoned, as it is a horrid format.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Well, I'm sorry if OGG doesn't require the silence at the beginning of the audio file to be cut off so that it syncs in most players, and god forbid someone get's a player that actually compensates for the delay automatically, undoing the work intended to keep it in sync.
That, and you'd be surprised on how much of a standard MKV is.
OGG should be abandoned, as it is a horrid format.
Do you mean that Vorbis is a horrid codec? I don't regard Vorbis as a horrid (or even bad) codec (Then there's another codec associated with OGG: Theora, which I do think is horrid).
Yes, Vorbis is a horrible and non-standard codec. I dont know what you're talking about with AAC needing to be delayed to sync or whatever. I have muxed hundreds if not thousands of videos to MP4 with AAC, both HE, LC and Parametric Stereo and none of them were ever out of sync. The only time it was out of sync was when I tried the DeDup method you guys seemed to have moved onto here.
Anyway, can we please get back to the original topic. How do I use NHML Fixup with Lua? I have the .lua file, what do I do now? Double-clicking does nothing and I have no idea what Lua is.
I dont know what you're talking about with AAC needing to be delayed to sync or whatever. I have muxed hundreds if not thousands of videos to MP4 with AAC, both HE, LC and Parametric Stereo and none of them were ever out of sync.
Are you sure? The desync is quite subtle (but definitely there, at least with some players).
Santiago wrote:
Anyway, can we please get back to the original topic. How do I use NHML Fixup with Lua? I have the .lua file, what do I do now? Double-clicking does nothing and I have no idea what Lua is.
On command line (you can also use batch files):
lua NHMLFixup-v7.lua <video-nhml-file> <audio-nhml-file> <timecodes-file> [tvaspect]
(tvaspect specifies that output should have 4:3 aspect ratio (meant for TV display). Should be used for everything except what has internal display.
Are you sure? The desync is quite subtle (but definitely there, at least with some players).
Positive. MP3 does have a delay, not much, but a delay nonetheless which makes it a bitch to do a waveform subtraction for quality comparison because you have to know exactly how many samples at the beginning to delete to allign it with the original wav. With AAC I have never had that problem.
If you did, you are pretty damn special, because I couldnt screw up an AAC audio track even if I genuinely tried.
On command line (you can also use batch files):
lua NHMLFixup-v7.lua <video> <audio> <timecodes> [tvaspect]
Never mind, I figured it out. I was still using the outputs from the NHML Transform script instead of following the instructions for the NHML Fixup script. I assumed there was a common denominator, looks like I was wrong.
Thank you Ikari for this great tool.
Because you have helped me, I feel it is my duty to give something back to this site. I can only offer you my sincere advice to not use the low quality setting you are currently using for AAC. Use -q 0.35 instead of 0.25. If you must use 0.25, add -LC to disable SBR whos artifacts especially stand out for the kind of waveforms NES audio has.
And please just ditch Vorbis and OGM entirely, it SUCKS.
Use -q 0.35 instead of 0.25. If you must use 0.25, add -LC to disable SBR whos artifacts especially stand out for the kind of waveforms NES audio has.
You happen to know the delay in samples for -q 0.35? Or how -LC affects the delay at -q 0.25?
And yes, that delay exists. Measured[1] at 2624 samples for NeroAACEnc -q 0.50 and 4672 samples for NeroAACEnc -q 0.25.
Oh, and some other AAC encoders give other amounts of delay (like one other (not very good) encoder gives 1024 samples of delay).
[1] The delay is measured by encoding couple periodic signals[2], decoding them back, measuring the phase difference for each and then using CRT to get the actual delay.
[2] For example, signals with period of 127, 131 and 137 samples can be used to determine any delay 0-2279268 samples (that upper bound is certainly big enough).
I don't really understand what does it matter if it might not be a standard officially recognized by some international standardization committee. What's important is not that it's standard, but that it's popular and widely supported. (I'm pretty sure you could search an official international standard for a really obscure audio format which basically no media player supports. The argument "but it's standard" wouldn't be of much help.)
And yes, that delay exists. Measured[1] at 2624 samples for NeroAACEnc -q 0.50 and 4672 samples for NeroAACEnc -q 0.25.
Prove it. Nero encoder only please.
I don't really understand what does it matter if it might not be a standard officially recognized by some international standardization committee. What's important is not that it's standard, but that it's popular and widely supported. (I'm pretty sure you could search an official international standard for a really obscure audio format which basically no media player supports. The argument "but it's standard" wouldn't be of much help.)
If a standardized format is obscure its probably because it once was a standard a very long time ago, like MPEG 1. Independent works like OGG are not reliable because they are built by enthusiastic hobbyists, not professionals. MPEG on the other hand always works to build and improve upon new standards that are guaranteed to be widely supported and continuously developed.
Does Vorbis have the advanced features of AAC, like SBR, or parametric stereo? No? Thats what I thought.
Vorbis is the equivalent of what the Snow codec is to x264. Its a great idea and all and good to see so many young people today into intellectual hobbies like these, but wavelet codecs have failed to compete with the impressive quality that the official DCT-based H264 standard has demonstrated. So I find it foolish to support it until it can demonstrate otherwise.
If a standardized format is obscure its probably because it once was a standard a very long time ago, like MPEG 1.
I'm not sure we are talking about the same thing when we are using the word "standard". What do you mean "it once was a standard a very long time ago, like MPEG 1"? You mean MPEG 1 is not a standard anymore? Do standards expire?
Standardization is no guarantee of quality, popularity nor support. Likewise non-standardization isn't guarantee of the opposite.
MPEG 1 has been superseded by MPEG 2, MPEG 2 has been superseded by MPEG 4 part 2, MPEG 4 part 2 has been superseded by MPEG 4 part 10 which is H 264. They are direct ancestors of one another. Using an outdated codec that has been the state-of-the-art standard a long time ago as an example of an obscure codec that you can find on the ISO/ITU website is a pretty retarded argument to make IMO.
Using an outdated codec that has been the state-of-the-art standard a long time ago as an example of an obscure codec that you can find on the ISO/ITU website is a pretty retarded argument to make IMO.
You get no argument from me on that, given that it was you who brought up the whole MPEG 1 as an example of an "obscure standardized codec".
Now, let's decode this again using some representative piece of software. ffmpeg is a good candidate for this, as it powers a lot of media players / decoders our viewers are using:
ffmpeg -i encoded.mp4 output.wav
Now, comparing the resulting waveforms in Audacity:
The output shows a significant delay. QED.
Incidentally, you can inspect the three files here if you don't have the means to generate them yourself.
The output shows a significant delay. QED.