StaxRip

[44vince44]

Atlantis:

JKyle has given you 4 suggestions for your pixelation problem.
The following is the one to test first.
2) Try LSMASHVideoSource or LWLibavVideoSource.

But as for the 1st suggestion, ffms2 included in staxrip 2.1.7.0 is already latest one of StvG.

If you have the source video, you can reopen it in staxrip, and open preview, and seek to the part that has pixelation.
By using preview, you can always check that the file is decoded properly, and if not, try another source.

If your source opens ok with ffms2 (FFVideoSource) according to the preview, no pixelation, then that could indeed be related to pausing the encoding process, and should be investigated further.

[Atlantis]

I have encoded the same source again with the same settings with no pixelation at that point but the situation has changed it is now with
StaxRip : 2.1.7.3
x265 3.4+62-aMod-gcc10.2.1+opt msg7086/DJATOM

So again no solution has been given yet.

Please focus on this question. Very simple question. The encode could be from a month ago, from a year ago, from 2 years ago.
How can I immediately after the encode, check to see if everything went ok. How to know if no pixelation occurred? That is the question.

[DJATOM]

Issue in progress. Once issuer confirms that my fix is working, I'll make a new x265-aMod release.

[JKyle]

How can I immediately after the encode, check to see if everything went ok. How to know if no pixelation occurred? That is the question.

AFAIK, there's absolutely NO WAY to find out such an issue beforehand or right after the encode UNLESS you view the preview or output with bare eyes.

StaxRip does not issue an error unless a filter issues one. If the source filter/decoder skips pixelated frames for whatever reasons, no errors will be shown. (When I was mentioning errors in the main window, I was talking about this general process.)

StaxRip is not an AI machine. Why don't you try out @44vince44's suggestions first? :(
And if you find out any good solutions to your issue, please share them. That's what this forum is for.


ADDED:

You asked how I found this sort of problem? My answer: bare eyes.
Only after watching the video in full could I see there was a problem with it.

Then why StaxRip or other apps didn't issue an error? Because no filters/plugins/tools reported an error at the time of working on it.

Why filters/plugins/tools didn't report an error? That's what is called a 'bug'.
At this time, you have two choices: report the bug to the developer, or just ignore it.

[Atlantis]

I'm going to ignore it for the moment. This has happened to me only one time after all these years, so it's like nothing in comparison. I can only confirm that
ffmpeg.exe -v error -i file.mkv -f null - >error.log 2>&1
does not detect it. But if with an hex editor, I change few bytes in a video, that thing can detect the problem!

This is an interesting thing/challenge for someone to write a software to monitor this anomaly during encodes.

[JKyle]

Maybe this thread (https://forum.videohelp.com/threads/400446-Repair-missing-pixels-in-video) on VideoHelp can be of help.
As for me, I haven't followed up with @johnmeyer's last post, but I'm willing to try his 'solution' in case I encounter a similar problem.

ADDED:
But I don't know if this is going to be the catch-before-you're-robbed solution either.
Is it even possible to predict whether there will be a pixelation issue before actually previewing or encoding?
I have no idea. :confused:

[DJATOM]

I believe sar 9:16 is correct. Let's see what our friend DJATOM thinks about it.

This thread may be helpful:

http://rationalqm.us/board/viewtopic.php?f=8&t=895

VSPipe simply ignores SAR and it's hardcoded in Y4M header as A0:0. So I decided to mimic that by default and allow user to follow script's PAR via reader option (if user knows what he's doing).

[videoh]

Meanwhile I have corrected DGSource() to return the PAR.

[JKyle]

Meanwhile I have corrected DGSource() to return the PAR.

That's pretty good news! :thanks: a million.


ADDED:

I've confirmed that with --reader-options use-script-sar=1 enabled in the new x265-x64-v3.4+70-aMod-gcc10.2.1 build (https://github.com/DJATOM/x265-aMod/releases/tag/3.4%2B70) by @DJATOM, the new DGSource binary passes on the correct SAR value to x265.

https://i.imgur.com/9PAwQHS.jpg

[stax76]

Now all I want to do is keep them at AC3 but boost the sound slightly using this custom command -af
dynaudnorm=p=0.94:m=70:s=22 though it won't let me keep the 256k bitrate at the same time as using the command.

Is there a way of getting Staxrip to let me keep the same audio bitrate of 256kbps and use the custom command.

256 is not specification compliant I guess, but you can use 224 or 384 instead.

For dynaudnorm there is GUI support however.

I just updated staxrip and every time I launch it I get a pop-up dialog with the error:

Load VapourSynth first
Filters > Filter Setup > VapourSynth

I can't find Load VapourSynth first in the source code, maybe try the last beta.

Why it keeps on using --range limited even if I put "full" in x265 options?

It imports color settings from the source:

Options > Video > Import VUI metadata

The source file is also not corrupt. What can cause the corruption during the encode? Can pausing cause this?

Pausing could be one of possible reasons.

2.1.7.6 Beta

- Apps dialog allows custom paths to AviSynth and VapourSynth portable (stax76)
- Installed AviSynth don't has to be located in System32, it can be installed anywhere using the included install.ps1 powershell script (stax76)
- NVEnc parameter fixes and option re-organisation (Dendraspis, #468)
- NVEnc gets '--vpp-warpsharp' options and a Sharpness subsection (Dendraspis)
- x265 two parameters not set when checkbox unchecked (Dendraspis)
- Optional customized/shorter progress text while encoding for x264/x265 (Dendraspis)
- Fix Re-mux TS to MKV via ffmpeg doesn't demux AAC tracks with ADTS (Dendraspis, #483)
- x264 portable mode uses DJATOM Mod --synth-lib (stax76)
- x265 portable mode uses DJATOM Mod --reader-options library (stax76)
- Command line preview uses scrollbar in case > 9 lines (stax76, #481)
- x265 3.4+70-aMod-gcc10.2.1 DJATOM Mod, avs portable support, vs async frame requests logic overhaul (#470)
- FFT3dGPU 0.8.6
- x264 aMod-core161-r3039+17 DJATOM (--synth-lib)
- nvenc 5.26

[tormento]

Now all I want to do is keep them at AC3 but boost the sound slightly
I suggest you to use -af dynaudnorm=f=2000:g=23:m=15:r=0.9 for movie audio.

[JKyle]

256 is not specification compliant I guess, but you can use 224 or 384 instead.

Uh... Well, @stax76, 256kbps is supported by ffmpeg.

I tried encoding ac3 at 256k on cmd and it succeeded.

D:\Tmp>[...]\ffmpeg.exe -i [...]\test.mkv -c:a ac3 -b:a 256k -af dynaudnorm=p=0.94:m=70:s=22 -y -hide_banner "[...]\test_temp\ID1 -1ms Japanese_1244133631.ac3"
Input #0, matroska,webm, from '[...]\test.mkv':
[...]
Stream mapping:
Stream #0:1 -> #0:0 (flac (native) -> ac3 (native))
Press [q] to stop, [?] for help
Output #0, ac3, to '[...]\test_temp\ID1 -1ms Japanese_1244133631.ac3':
Metadata:
encoder : Lavf58.65.101
Stream #0:0(jpn): Audio: ac3, 48000 Hz, 5.1(side), fltp (24 bit), 256 kb/s (default)
Metadata:
BPS-eng : 1574975
DURATION-eng : 00:01:43.338000000
NUMBER_OF_FRAMES-eng: 1211
NUMBER_OF_BYTES-eng: 20344357
_STATISTICS_WRITING_APP-eng: mkvmerge v46.0.0 ('No Deeper Escape') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2020-05-18 11:17:08
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
encoder : Lavc58.117.101 ac3
size= 3230kB time=00:01:43.32 bitrate= 256.1kbits/s speed=78.4x
video:0kB audio:3230kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

I've verified that even 128kbps is supported as well.

In fact, I see that ffmpeg adjusts the input bitrate to a nearby supported one in encoding, so I guess bitrate restriction for ac3 in StaxRip is meaningless.

IMHO, we need to fix this. :)

[MrBrownCow]

Trying 4k HDR x265 encode for the first time. I checked "HDR Ingest" and "Import VUI metadata" before starting. It seems to have completed after 22 hours because it produced an mkv file but I got an error during the muxing process at the end. File still plays but I'm assuming some kind of issue writing the HDR data?

Anyone know what this means?
https://imgur.com/a/iobSuRo

[JKyle]

I'd recommend NOT to use HDR Ingest: it simply remuxes the original source video to an mkv file with HDR VUI metadata, but the metadata itself is incorrect depending on the sources.
Use Import VUI metadata only.

See this issue (https://github.com/staxrip/staxrip/issues/421) and @Dendraspis's reply in here (https://github.com/staxrip/staxrip/issues/427#issuecomment-756984992).

IMHO, it will be eliminated from StaxRip in the end.

And before you report some issue, don't forget to try the most recent beta.

[JKyle]

For those who are not familiar with two newly introduced features, I've written posts in the Wiki.

Please see these in case you're interested.

x264/x265 Custom Quality Definitions (https://github.com/staxrip/staxrip/wiki/x264-x265-Custom-Quality-Definitions)

x264/x265 Customized Progress Text Tweaks (https://github.com/staxrip/staxrip/wiki/x264-x265-Customized-Progress-Text-Tweaks)

:)

[stax76]

Uh... Well, @stax76, 256kbps is supported by ffmpeg.

I've moved the warning to the main dialog, so it's possible to ignore the warning.

[lordalibaski]

Thanks for looking into this everyone, I converted it with eac3 at 256k and with the command and it worked fine.

I've done quite a lot of them at 224 or 384 but wanted to keep the same audio bitrate but boost the sound slightly on a few of them, with them being VHS tapes some are quite low.

[stax76]

2.1.7.7 Beta

- VPY files failed to import (stax76, #486)
- Warning for non-spec compliant AC3 bitrate moved to main dialog, so it's possible to ignore the warning (stax76, JKyle)
- avs2pipemod mod with Unicode and Long Path support (stax76)
- .aac files demuxed with mkvextract are no longer converted to .m4a (stax76, #489)
- x264 --fade-compensate --log-file --log-file-level --opts --progress-header (stax76)
- mkvtoolnix 53

[tormento]

If you want to open dgi, then it's simple:
Either StaxRip has changed interface since that post or today I am a bit dumb. How am I supposed to add DGI reading?

[JKyle]

On the repo Wiki: here (https://github.com/staxrip/staxrip/wiki/How-to-register-DGDecNV(DGSource-and-DGIndexNV)-in-StaxRip).
Or you can search the two StaxRip related threads in this forum for related posts.

BTW, the post you quoted is more than half a year ago. It's history for a fast developing software program like StaxRip.

[tormento]

On the repo Wiki
:thanks:
BTW, the post you quoted is more than half a year ago. It's history for a fast developing software program like StaxRip.
Yes, I noticed. Last time I tried StaxRip, DGIndexNV was included. ;)

[tormento]

On the repo Wiki
Tried and works fine but the preprocessor part. Why the Index, No demux and Index & Demux have different input formats? Just as example or there is some limitation?

[JKyle]

It was to follow suit for the already existent DGIndex preprocessor case.
Suit yourself.

[JKyle]

2.1.7.8 Beta is released.

- Support 10-bit avs input for x264 in case the x264 version name contains the keyword aMod (stax76)
- AviSynth portable mode no longer uses soft links but moves files if necessary (stax76, #473)
- For x264 and x265 different code paths are used depending if the version name contains the keywords aMod or Asuna, Vanilla builds are supported as well (stax76)

---

Customized/shorter x264/x265 progress text is enabled by default.

Don't forget to overwrite StaxRip.exe included in the 7z file with the hotfix StaxRip.exe.
Otherwise, you'll run into a pop-up error on the first launch.

---

ADDED:

IMHO, some explanation is due for this version.

So far ffmpeg has been the only hurdle for portability.
(All other tools - including mod versions - started supporting portable AviSynth by incorporating a command line option to call portable AviSynth.dll.)

Since ffmpeg does not accept PATH environment created by a StaxRip session, StaxRip has adopted so far a soft link to portable AviSynth.dll to force its priority on ffmpeg (over system AviSynth.dll).

But since many people are experiencing issues with this 'soft link' method, StaxRip changed its internal design to avoid this fuss, starting this version 2.1.7.8.

Now StaxRip moves ffmpeg.exe itself to the same folder as portable AviSynth.dll. This way, portable AviSynth.dll has priority over system AviSynth.dll for ffmpeg.exe by default.

However, in case ffmpeg needs to use system AviSynth.dll instead of the portable one, ffmpeg.exe is moved back to the folder %startup_dir%Apps\Encoders\ffmpeg\.

There's a catch here. It's not moved readily to the new location by the user's Frameserver Mode setting. It moves based on demand: that is, only when the system AviSynth.dll is needed by ffmpeg.exe.

I also misunderstood the mechanism and reported this as a bug. See this issue thread (https://github.com/staxrip/staxrip/issues/491) for further information.

I hope you don't make the same mistake. :)

[44vince44]

Thanks JKyle for taking time to explain all this ! It's a relief to see that a simple solution has been found to remove the complexity of soft links!

[stax76]

There's a catch here. It's not moved readily to the new location by the user's Frameserver Mode setting. It moves based on demand: that is, only when the system AviSynth.dll is needed by ffmpeg.exe.

I admit it's a little confusing, it's designed that way for the best possible performance.

[JKyle]

Oh, never mind.
Actually I think it's more suitable... and smart. ;)

---

BTW, I put a section on the Wiki ffmpeg page (https://github.com/staxrip/staxrip/wiki/ffmpeg) about this whole change.
As you may know, you are redirected to the Wiki page if you click on Apps Manager(F9) > ffmpeg > Help > Wiki.

[stax76]

Thank you for working on the wiki, that will be helpful for people who want a deeper understanding how things work.

[Bandido]

Greetings.
First of all, thank you for your work.
A question.
In the audio option copy / mux does not take into account the delay ?.
Sorry for my Google English

[stax76]

2.1.8.0 Stable


"Import VUI metadata" also imports Chromaloc (Dendraspis)
"Import VUI metadata" sets "--hdr10" (Dendraspis)
.aac files demuxed with mkvextract are no longer converted to .m4a (stax76)
Add 'ShowCodePreview' to commands list (Dendraspis)
Advanced Info feature of Code Editor has new VapourSynth ClipInfo option. (stax76)
Audio source file bitrate detection fix (stax76)
Auto-Rotation feature for supported source files/container (Dendraspis)
AviSynth 3.7
AviSynth portable mode no longer uses soft links but moves files if necessary (stax76)
avs2pipemod mod with Unicode and Long Path support (stax76)
avsresize r5
BAT and PS1 scripts to install and uninstall AviSynth and VapourSynth portable system wide are located at Apps\FrameServer\Install (stax76)
Command line preview uses scrollbar in case > 9 lines (stax76)
D2VSource 1.2.2
DgMpgDec 2.0.0.2
ffmpeg can be used as pipe tool for VapourSynth and x264/x265 (Patman86)
FFT3dGPU 0.8.6
Fix items can't be removed from or rearranged in lists (Dendraspis)
Fix randomly appearing IOException when using x265 with chunks (Dendraspis)
Fix Re-mux TS to MKV via ffmpeg doesn't demux AAC tracks with ADTS (Dendraspis)
Fix weird behaviour on Audio Settings for qaac (Dendraspis)
Full AviSynth Unicode support for users of Windows 10 1903, Windows 7 users need to enable avs2pipemod for x265 in order to use foreign characters
Full long path support for users of Windows 10 1903
Get-MediaInfo shows Range, Primaries, Transfer, Matrix. (stax76)
Main dialog shows actual video width and height. (stax76)
Make forced shutdown optional via settings (Dendraspis)
Menu in the code editor can be customized and is much faster (stax76)
Messagebox when processed file or its project file is not found instead of crash (Dendraspis)
mkvtoolnix 53
MP4Box 1.1.0-rev447-g8c190b551-gcc10.2.0 Patman (Windows 10 long path support added)
MP4Box can import EAC3 (stax76)
Neo DFTTest is now also available for AviSynth. (stax76)
Nero AAC encoder binaries removed due to license issue. (stax76)
New feature to automatically fix bad frame rates (stax76)
New feature to automatically save projects (stax76)
New VideoFilter "ChangeFPS" for AviSynth (Dendraspis, 44vince44)
New VideoFilter "Rotation" (Dendraspis)
nvenc 5.26
NVEnc gets '--vpp-colorspace' options (Dendraspis)
NVEnc gets '--vpp-warpsharp' options and a Sharpness subsection (Dendraspis)
NVEnc option --timecode (stax76)
NVEnc parameter fixes and option re-organisation (Dendraspis)
Options dialog starts faster. (stax76)
Processing form remembers its size (stax76)
QT libraries will be found if located at Apps\Audio\qaac, Apps\Audio\qaac\QTfiles64, download button points to wiki page with install instructions (stax76)
rav1e 0.4.0
rav1e speed control has hint text: 0 = Slowest, 10 = Fastest (stax76)
Revert current folder of process being set to video temp folder because it locks the folder and also because the .NET Framework allows only 260 characters for the working directory of a process. (stax76)
Show also Source HDR Format on main window (Dendraspis)
Source information shows the video stream size instead of file size, if not available the file size is shown in brackets (Dendraspis)
Using neo functions caused non neo plugins being loaded without reason (stax76)
VapourSynth portable allows custom path in Apps dialog (stax76)
VapourSynth scripts failed to import (stax76)
VCEEnc uses --avsdll in portable mode (stax76)
Warning for non spec compliant AC3 bitrate moved to main dialog so it's possible to ignore the warning (stax76, JKyle)
WorkingDirectory property of ExecuteCommandLine command supports macro expansion, Windows Terminal menu item uses the video temp folder as current directory. (stax76, JJKylee)
x264 aMod-core161-r3039+17 DJATOM (--synth-lib)
x264 --fade-compensate --log-file --log-file-level --opts --progress-header (stax76)
x264 portable mode uses DJATOM aMod --synth-lib (stax76)
x264 supports 10-bit avs input in case the x264 version name contains the keyword aMod (stax76)
x264/x265 custom quality definitions via Settings > Video (Dendraspis)
x264/x265 optional customized/shorter progress text while encoding (Dendraspis)
x265 3.4+70-aMod-gcc10.2.1 DJATOM Mod, avs portable support, vs async frame requests logic overhaul
x265 command line preview shows both passes for two pass (stax76)
x265 don't use a pipline for chunks if no pipeline is set (Dendraspis)
x265 fixed default value for --hist-threshold (Dendraspis)
x265 '--high-tier' option moved to 'Basic' tab (Dendraspis)
x265 muxing won't mux chunks from recent encodes (Dendraspis)
x265 options set chromaloc automatically to 2 if HDR is set to "Yes", to 0 if HDR is disabled or keep it untouched if "Undefined" (Dendraspis)
x265 Pipe option is invisible if decoder is not set to AVS/VPY (Dendraspis)
x265 portable mode uses DJATOM aMod --reader-options library (stax76)
x265 --seek and --frames also work with chunks (Dendraspis)
x265 two parameters not set when checkbox unchecked (Dendraspis)
x265 UI bug in preset VerySlow showing unnecessarily default values in command line (Dendraspis, stax76)
x265 UI issue fix (stax76)
x265 --version output is used in order to detect if it's aMod, Asuna or Vanilla, different code paths are used to fully support any kind of build (stax76)

[stax76]

In the audio option copy / mux does not take into account the delay ?.

It should be detected from the filename and can be configured in the mux audio options.

[44vince44]

bandido, it works all right. What container are you using ? MKV ?

[44vince44]

@Stax76: thanks for this new release !
And also Thanks to @Dendraspis @Jkyle and all people involved !

[JKyle]

@stax76,

Thanks for the update 2.1.8.0.

BTW, looking into the folder structure, I've found that you need to merge the following to files

%startup_dir%Apps\Conf\MPC-BE.conf
%startup_dir%Apps\Conf\MPC-HC.conf

into

MPC.conf

like in Apps Manager.

[Atlantis]

Can we copy this new version over the old or better to do a clean install?

[JKyle]

Overwrite the old files only if you know what you're doing.
Otherwise, clean install is always recommended.

[Atlantis]

I mean are there fundamental changes in the config files since 2.1.7.0-Stable? I prefer not to do a clean install because it takes time to reconfigure everything.

[NanoBot]

I just updated from 2.1.7.0 to 2.1.8.0 by keeping only the settings folder, and until now, everything works fine. All my settings and templates are intact.

[stax76]

@JKyle

Starting with the next build orphaned .conf files are deleted automatically on startup.


@Atlantis

A clean installation is usually more safe.

[JKyle]

@JKyle

Starting with the next build orphaned .conf files are deleted automatically on startup.

Sounds reasonable. :)

[stax76]

I mean are there fundamental changes in the config files since 2.1.7.0-Stable? I prefer not to do a clean install because it takes time to reconfigure everything.

The installation folder should normally be replaced completely.

The settings/projects/templates can usually be kept, sometimes there can be issues, but they can usually be fixed individually without resetting settings/projects/templates completely. Some precaution and experience can help. For instance, we had an issue with a x265 setting that was slowing down encodes, I never knew when and why it happened. But it's usually easy to spot because the command lines can be previewed and seen in the log file and the defaults are minimalistic.

[JKyle]

In my experience, the following steps usually work (except for some minor issues) when you decide to overwrite files:

1) Extract the new version to a separate folder.
2) Keep %settings_dir% of the old version.
3) Overwrite all the others of the old version with files in the new version. (And clean up orphaned files.)
4) Launch your existent version.
5) Launch the new version.
6) Update your custom AVS/VS profiles, Video/Audio encoder profiles, menus (main, crop, preview, code editor) referring to the new version. (If you can use git, it helps a lot in this step.)
7) Fix minor issues on Apps Manager(F9): location, version, etc.
8) Load your templates and see if there are any unwanted parameter changes.

[tormento]

It was to follow suit for the already existent DGIndex preprocessor case.
I tried but while audio and subs are correctly demuxed in the _temp directory, the attachments in mkv files, such as the ttf needed by ass subtitles, are extracted in the same directory of the source file. Opening the container options I can see they are not present in the files to be remuxed at the end of the encoding.

Any idea how to fix this? Perhaps have Matroska to demux streams and DGIndexNV to work on video only?

[JKyle]

I tried but while audio and subs are correctly demuxed in the _temp directory, the attachments in mkv files, such as the ttf needed by ass subtitles, are extracted in the same directory of the source file.

I rarely work on such files.

You can still manually add the attachments in the mkv container configuration.

Or if you don't like the way they are demuxed, try running the DGIndexNV.exe command on CMD with the macro %temp_file% being expanded. And if they still don't demux in the same folder, I guess it's something you need to ask the DGIndexNV developer.

[tormento]

And if they still don't demux in the same folder, I guess it's something you need to ask the DGIndexNV developer.
Manually invoking DGIndexNV of course demux all in the same directory. I have some suspicion that then StaxRip moves and renames tracks and forgots TTF.

[Bandido]

It should be detected from the filename and can be configured in the mux audio options.

If that's what I did, both video and audio with the copy / mux option set the delay times but had no effect.


bandido, it works all right. What container are you using ? MKV ?
yes MKV

[stax76]

@tormento

I cannot reproduce it, here attachments are correctly extracted in the _temp folder and then found, maybe you can post the full log to pastebin.com.

-------------------------- Demux attachments --------------------------

mkvextract 53

Z:\StaxRip\Apps\Support\MKVToolNix\mkvextract.exe "Z:\Samples\ASS Subtitles.mkv" attachments 1:"Z:\Samples\ASS Subtitles_temp\ASS Subtitles_attachment_OpenSans-Semibold.ttf" 2:"Z:\Samples\ASS Subtitles_temp\ASS Subtitles_attachment_rick_and_morty-d9h2vl6.ttf"

File 'Z:\Samples\ASS Subtitles.mkv': container: Matroska
Track ID 0: video (MPEG-H/HEVC/H.265)
Track ID 1: audio (AAC)
Track ID 2: audio (AAC)
Track ID 3: subtitles (SubStationAlpha)
Track ID 4: subtitles (SubStationAlpha)
Attachment ID 1: type 'application/x-truetype-font', size 221328 bytes, file name 'OpenSans-Semibold.ttf'
Attachment ID 2: type 'application/x-truetype-font', size 17704 bytes, file name 'rick_and_morty-d9h2vl6.ttf'
Chapters: 5 entries

The attachment #1, ID 15572473706801175955, MIME type application/x-truetype-font, size 221328, is written to 'Z:\Samples\ASS Subtitles_temp\ASS Subtitles_attachment_OpenSans-Semibold.ttf'.
The attachment #2, ID 7219417645334414226, MIME type application/x-truetype-font, size 17704, is written to 'Z:\Samples\ASS Subtitles_temp\ASS Subtitles_attachment_rick_and_morty-d9h2vl6.ttf'.

Start: 17:54:00
End: 17:54:01
Duration: 00:00:00

[stax76]

If that's what I did, both video and audio with the copy / mux option set the delay times but had no effect.

Maybe post the mkvmerge muxing command line found in the log file.

[tormento]

I cannot reproduce it
Of course you can't, I am talking about DGIndexNV as preprocessor, you are using MKVExtract. :p

[videoh]

Next DGDecNV slipstream will demux chapters from MKV when the CLI -a is given. I've linked a test build at my forum.