automatic-ripping-machine
automatic-ripping-machine copied to clipboard
automatic-ripping-machine
Specific Handbrake settings for 4k Blueray
Description
It is nice that we can specify different transcoding flags for DVD and Bluray's (HB_ARGS_DVD HB_ARGS_BD) Would it be possible to add an addition option for 4k Blurays (possibly HB_ARGS_4K_BD)? For (normal 1080) Blurays I transcode with diff settings than UltraHD Blurays (4k).
I haven't looked into the code in this project and have never touched python so don't know how much help I would be in implementing but might be able to figure it out with enough guidance.....
@PartemImperium @trevordavies095 Y'all are referring specifically to UHD disks, correct?
I can add handling for this case as part of the logic rewrite if someone can figure out how these disks appear when identify.py gets the data from them. I don't have any UHD disks or a drive capable of reading them, so I can't implement this on my own.
@shitwolfymakes I have the ASUS BW-16D1HT which is capable of doing 4K UHD rips. I popped in a 4K UHD copy of Dune, ARM read and ripped the disk just fine. Transcoding though is taking forever, but I am running ARM on an older Xeon that only does 2.13GHz.
ARM is installed in a Podman container on Fedora Workstation 37, using this docker image docker.io/1337server/automatic-ripping-machine:latest
I can provide some logs if needed.
I've got a drive and disc and started gather logs here: https://gist.github.com/simcop2387/819fce421060cbd10b5bfea54a7efed9
It doesn't look like there's anything obvious from the things that are already gathered in identify.py, or that i see on the disc itself, so it might be that it can only be detected after the fact and looking at the resolution of the raw files from makemkv. I don't have the makemkvcon info log in there yet but it's being created right now and i'll update the gist with it once it's there.
edit: logs are in place now
I am considering looking into this to see if I there is something I can contribute for it. Do we have consensus that the only way would be to detect resolution after video files have been ripped? If so, then I think I would take a look at possibly inserting a test/branch case for the raw .mkv files (although largely speculative for now), does this sound like the correct approach?
