Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Source notes:
- - The default tracks are 'English' for the audio and 'Signs Only' for the subtitles. This is just a personal preference, but if that bothers you, you can use JMkvpropedit (https://forum.doom9.org/showthread.php?t=163753) to change that in about 20 seconds without remuxing. Simply load up all the files, head to the audio tab, hit the + button twice, change Track 1 from Default: "Yes" to "No", and Track 2's default from "No" to "Yes. After that, jump over to the Subtitles tab, hit plus twice again, and change Track 1 from Default: "No" to "Yes, and Track 2 from "Yes" to "No". Press "Process Files", wait a second for it to do its thing, and you're good to go.
- - Note that the dub audio has a few technical errors beyond my control. For example, episode 40 @ ~16:39 and episode 46 @ ~8:16 feature a small pop mid-sentence. This is present on both the raw BDs and the Adult Swim broadcasts, so is clearly a problem on Viz's end. Those were the only episodes I noticed with issues - it's not an experience ruiner, thankfully.
- - The OVA included is 29.976fps progressive with baked-in interlacing artifacts. There is no better source.
- Why are the files quite large, isn't HEVC supposed to be small?
- They're actually pretty much bang in line with most HEVC encodes of these standards, particularly when taking into account the show's visual style (see Beatrice-Raws' uploads). Boruto uses a great deal of intense lighting effects, is packed full of action (much of it at night), and on top of that, it's covered in a layer of active grain (not dithering noise). As I'm sure you know, these all require huge amounts of bitrate to prevent artifacting, so with all that considered, these are pretty small for a 1080p BD with these components. You could certainly degrain it and cut the file size down significantly, but I'm not particularly interested in going against the director's wishes. As it stands, these are virtually transparent, and I'm very happy with how they turned out. The comparative x264 encodes of this quality were double the size! That said, you are more than welcome to use them as a basis for a mini-encode :)
- Okay, but why FLAC then? You could maintain the same quality with other formats and save space?
- Correct! To be perfectly frank, I had no intentions of using FLAC, and I hate that I had to. My first runthrough used OPUS, then AAC, then I ultimately gave up and fell back FLAC as it was the only format that failed to break. I don't know if it's a bug with HEVC, Viz authoring the BDs weirdly, or just my own incompetence somehow, but anything but FLAC turned the video's frame rate variable or broke the runtime. I initially got around this by encoding the audio and muxing independently from the video, but this just resulted in sporadic pops in various episodes' audio, despite them not being present in the original files. I figured it might have been a timecode discrepancy between the tracks or a key frame issue from splicing the remuxed MKVs since demuxing the problematic files removed the popping, but even encoding directly from the individual M2TS files produced the same issue. Never in my life have I come across an issue like this, and it stumped my most advanced encoder friends, too. If you have any ideas what on earth's going on there, I'd love to know. x264 didn't seem to cause as many problems, so I'm fairly sure it's an HEVC thing? Either way, the release you have here is functionally fine, but I figured I'd explain the FLAC headassery as that's always a point of contention in this community.
Advertisement
Add Comment
Please, Sign In to add comment
