x264 rev2208+677 tMod

Sources on GitHub: https://github.com/astrataro/x264_tMod.

Use win32thread and fprofiled:
tMod／tMod-10bit／tMod+MixAQ／tMod+OreAQ:
Download:
x264_rev2208+677_tMod-Libav.7z : NMM、GitHub、MediaFire
x264_rev2208+677_tMod-FFmpeg.7z : NMM、GitHub、MediaFire
x264_rev2208+677_tMod-Lite.7z : NMM、GitHub、MediaFire

By default uses old style progress indicator, and won’t break GUI’s progress parser. If you like r2204 style progress indicator, try --stylish, but keep careful if you are using GUIs. The difference between r2204 and this --stylish is that console title always uses old style indicator, so you won’t get meaningless raw numbers without labels on console title.

Patches:
–—––—– Download: patches-rev2208.7z: NMM、MediaFire
00: L-Smash（including audio encoding）
01: Add an option to use r2204 style progress indicator (New!!)
02: More detailed version head
03: Add back “touhou” tune
04: Film Grain Optimization
05: Fade Compensation
06: Remove stats before renaming
07: Add a parameter to set level of writing options in User Data Unregistered SEI
08: Utilize internal threading in lavf/ffms
09: Auto VBV settings
10: AVI output
11: filters hqdn3d pad vflip yadif patch
12: Log file
13: Encoding time
14: Level force
15: Profile force
16: Cosmetic
17: New experimental AQ mode (modification of Auto-variance AQ)
18: Print video info with lavf/ffms demuxer
19: lto & Ofast
20: AviSynth 16bit hack
21: Skip bit depth filter when possible
22: Use f3kdb for bit depth conversion when needed
23: Video filter: subtitles
24: Detect color matrix with lavf/ffms demuxer
25: Fix AviSynth color space converting matrix
26: Fix swscale color space converting matrix
27: Support “dgi” file extension
28: Variable progress precision, print encoded file size & estimated total size (Updated!!)
29: More detailed “zones” help
30: Unofficial --device
31: Correct framerate of AviSynth to proper NTSC fraction if applicable (New!!)
32: Add “libaacplus”
33-1: MixAQ-core（only in tMod+MixAQ version, remove AQDebug）
33-2: OreAQ-core（only in tMod+OreAQ version, remove AQDebug）

—————————————————-
My other tools list ( including some of the x264 builds ) : MediaFire

fixtc for avs4x264mod

avs4x264mod automatically adds --timebase when using --tcfile-in since 0.7, but sometimes timecodes files are not accurate, and may break x264’s timecodes parser with correct timebase=1001/normal_NTSC_timebase_den. You can manually set --timebase to overwrite avs4x264mod’s decision, but it it not a good solution, as the problem is caused by the input timecodes files, and the value detected by avs4x264mod is more accurate than x264’s decision in such cases. Most of these timecodes files are generated by muxing video into matroska container and extracting timecodes from this mkv file, in which timestamp precision is by default reduced to 1ms when muxing. You can use --timecode-scale 1 to keep normal 0.000001ms precision when muxing with mkvmerge, if the input video’s timestamp is normal (e.g., when muxing standard NTSC mp4 into mkv, or specifying timecodes/fps when muxing). But it will increase the file size of muxed mkv files, and in most cases the source video one uses for encoding is not muxed by him/herself. So here I made a tiny tool for correcting such timecodes files.

Download – fixtc-v1.2.7z: MediaFire, NMM-Mirror
Edit: tctool-v1.3.44.7z
tctool is based on fixtc with richer features
old features work more stable for some strange timecodes, and some new features are still in TODO list
check tctool-help.txt/changelog.log/TODO in the archives file for details.

Usage(supports both timecodes v1 and v2)：
fixtc.exe "input_timecodes.txt"

Output will be printed on screen. If you want to keep it in a single output file, use system stdout redirection:
fixtc.exe "input_timecodes.txt" > "output_timecodes.txt"

The fps values in timecodes v1 and the intervals between two timestamps in timecodes v2 will be automatically corrected to NTSC values if capable. Don’t try to use it for non-NTSC contents. x264 should be able to parse PAL timebase properly, for which fps is either 25 or 50, and timestamps are either 40, 80, 120,… or 20, 40, 60,…, so normally you won’t lose precision.

Examples:

timecodes v1:
before fixed:
# timecode format v1
# comment lines will be copied
Assume 23.976
0,467,23.9754
468,547,29.9738
548,583,23.9840
584,623,29.9625
624,667,23.9782
668,722,29.9728
invalid lines will be prompted and skipped
723,762,23.9664
763,777,30.0000
778,805,23.9726
806,815,29.9401
816,895,23.9808
896,925,29.9700
926,1197,23.9753
after fixed:
# timecode format v1
# comment lines will be copied
Assume 23.976024
0,467,23.976024
468,547,29.970030
548,583,23.976024
584,623,29.970030
624,667,23.976024
668,722,29.970030
723,762,23.976024
763,777,29.970030
778,805,23.976024
806,815,29.970030
816,895,23.976024
896,925,29.970030
926,1197,23.976024

timecodes v2:
before fixed:
# timecode format v2
# comment lines will be copied
0
42
83
125
167
invalid lines will be prompted and skipped
209
250
292
334
375
417
# break at invalid timestamp(current timestamp is earlier than previous one)
300
501
542
after fixed:
# timecode format v2
# comment lines will be copied
0.000000
41.708333
83.416667
125.125000
166.833333
208.541667
250.250000
291.958333
333.666667
375.375000
417.083333
# break at invalid timestamp(current timestamp is earlier than previous one)