Closed otakukunsan closed 6 years ago
gnoling
commented
7 years ago I have doubts that you're still waiting on this, but if you're able I'd appreciate if you could see if the new build of the dist/ version resolves your issues. The old one, as you noted, was pretty outdated -- it used a fairly old version of unlinkmkv in addition to the old ffmpeg/mkvtoolnix.
otakukunsan
commented
7 years ago Hi,
I received your reply, but before I can even try running the new version, I need to let you know that there are some minor issues first.
Right off the bat, the new version specifies x64, but I'm using Windows 7 SP1 x86 to encode/remux videos. So basically I'm not sure the newest of UnlinkMKV will run under an x86 OS.
When it came to the previous build, I didn't comprehend the "fix video" or "fix audio" options, but I figured it out when the unlinked MKV's failed to be re-encoded properly. Basically, about a minute and a few seconds after the linked opening was re-encoded, it just ended. I tried re-encoding with Hybrid and Handbrake, and the results were the same both times. Then I tried using MKVCleaver to extract everything from the unlinked MKV, and MKVExtract stopped with an error. So I tried extracting everything one at a time, and both the video and audio failed to extract.
I haven't had a chance to sit down and really examine your script, but my suspicion is that unlinked MKV contents is not fully compliant with the MKV standard, or the latest MKVToolnix. Honestly, I don't much about either of them myself, but I did wonder something. I was wondering if without using either of the fix options, the script merges the segments using the same track number, and linking the segments using the identifier? For example, Track 1: Video (Opening ID#xxxxx), Track 1: Video (Main Body ID#xxxxx), Track 1: Video (Ending ID#xxxxx), and so on for Track 2: Audio.
Since I couldn't get the unlinked MKV to re-encode, extract all the contents inside the MKV container, I literally have no idea what went wrong. Just for giggles I also tried AVIDemux, and the same problem. Other than the strange issue with the subtitles not displaying properly only during the first playback, the unlinked MKV played fine using MPC-HC. So I figured this was where the "fix vodeo" and "fix audio" options came in handy. Unfortunately with the old version of UnlinkMKV, the options may be too restrictive.
In the script, under the following displayed output is the location in the script I am discussing:
INFO "encoding parts";
Yu Yu Hakusho - Episode 91, has an overall bitrate of 6,727 kb/s, but the opening due to it's smaller size has an overall bitrate of 12.5 MB/s, so that might be the issue when re-encoding or remuxing, but I don't know why it would be an issue when tring to extract the video and audio tracks. Obviously I would need to manually edit the script to change the encoding bitrate from your default value to at least 6,727 kb/s, but from what little I can understand of your script, in the old version of UnlinkMKV, it still left me with another problem. The test video was encoded with High 10, or 10-bit color, and I have no clue whatsoever as to how to encode using the CLI. In fact, the test video was encoded using a CRF=18.0 for Opening, Main Body Video and Ending, but once again I don't know how to use the flags, triggers, values, or whatever they are called. And since I have no idea how to adjust the bitrate to reduce banding when encoding from 10-bit color to 8-bit color, just so I can re-size to a lower resolution and re-encode back to 10-bit color, using an integer CRF value would make trial and error much easier.
The test video also wouldn't work well with the default audio encoding values because I would be encoding from FLAC 5.1 to AC3 Stereo. It's one thing to go from lossless or a bloated audio file to a lossy one, but there is no way to "fix audio" per the fault values and still retain 6 channel audio. Here again, my lack of experience encoding using the CLI is at fault, not your script.
Obviously somewhere all the information I need is documented, so not your problem, and I realize that fact. However, it would be really convenient if inside the ffmpeg folder there was a copy of how to use the CLI to allow someone to manually edit your script to try to retain as much of the original quality as is possible when using either or both "fix" options.
Again, not your problem. It's just that after posting to UnlinkMKV, I also came across something that bothered me quite a bit with UnlinkMKV-GUI. That developer offered me a workaround, but unfortunately I haven't had a chance to try it yet. By now you can tell that I like GUI's, and I wish that I could utilize the GUI to retain as much quality as possible. I have no idea how difficult it would be to swtich between bitrate and CRF, or 8 and 10-bit color in either the GUI or your script, but it would be nice to be able to do it.
The only other option that I could think of was to "call" the x264 or x265 interface up at the beginning of the script, and the lav audio codec, at the beginning of the script if either or both "fix" options are enabled. If you use the "Configure" button under Video in AVIDemux it does this, but their compiled x264 codec doesn't do 10-bit color. I think Handbrake and Hybrid uses the GUI, but the values are preserved somewhere to be run from the CLI. I don't even know how to change the identifiers to linked chapters or files, so I have no idea how to preserve as much of the original quality as I can before re-sizing and re-encoding.
The bottom line is I'm lost.
otakukunsan
commented
7 years ago Sorry, I was tired and made some typos, but I hope what I was trying to say made sense to you.
Hi,
It took me hours to get your program to run under Windows 7, so please, forgive me if I come across seeming really stupid right now.
I honestly have no idea why Log::Log4Perl appears to be a critical module for unlinking previously linked chapters, but I guess it is. I installed Strawberry Perl, verified that XML::LogXML (?) was installed correctly, but Log4Perl failed a test and refused to install. I tried a forced install, no test install, and a forced with no test install, and they all failed because a test was still run, and the test failed. I kept scrolling back through the CLI, and Log::Dispatch kept appearing, so I decided that I either didn't understand the output, or the output was just vague garbage. After going through a bunch of useless information in forums, I decided to install Log::Dispatch before installing Log::Log4Perl, because the only test I shouldn't be able to disable is a test for prerequisite dependencies. It worked, but I was ready to call it quits by then.
Just for the sake of trying I tossed everything into the same directory and manually edited the ini file. I had zero expectations at this point for a number of reasons. I know that some openings and endings have karaoke added through After Effects, and things like bit depth, frame rate, CRF and bit rate, and even screen resolution don't merge or encode well when combined with the "main" video. I was happily surprised to find that my test video, episode 91 of the 1080p version of Yu Yu Hakusho seemed to be successful. Maybe I'm wrong, but if the FFMPEG that's included is really from 2015, it could cause corruption when encoding to unlink ordered chapters if it's too out of date, or incompatible with playing back x265.
Anyway, the first time I tried to playback the unlinked video it started with no subtitles, but subtitles were enabled by default when merged. I turned the subs on and then off during the opening, and they came back on during the main video, turned them off again and they came back on during the ending. I exited MPC-HC, played the video two more times, and the subs were displaying correctly. So I'm not complaining, but if you have a moment I would be interested in your thoughts as to why the subtitles were acting weird only during the first time through, and I stepped through it by chapters, if that is useful.
Thanks.