In this thread you can post any suggestions you have on improving DeUHD. I will make sure to collect them once in a while and bring them to the attention of Arusoft.
Well, I have already posted this in another thread, but I do think that here is the correct place:
Indicate where you purchased the disc is not sufficient for sure
For Example there is two different “The Martian” disk for European market, with exactly the same UPC code, but different sha-1
I do sent them the AACS folder etc etc of the disk not supported and they after some hours opened it too
This way I do think that is necessary create a database where the customers can insert the info of their BD-UHD and attack the AACS Playlist CLIPINF folders together with the log, the UPC code and the SHA-1 of the key.
Doing this will be very more easy and accurate to identifie a bd-UHD title and know if it is already supported and if it is not, all the requested data will be accesible for Arusoft’s programmers and developers
DoMiN8ToR thanks for this opportunity to improve the software support.
this means that the source region or UPC code does not identify a title, the only parameter that identifies it is Hash SHA-1 file Unit_Key_RO.inf , and you can not know before buying a title if it is supported or not.
The need to create a database with UHD Blu-ray data can improve support, if Arusoft can automate it all.
I’d prefer that they do their weekly releases / SW updates at the end of the week (instead of Monday Morn) so we have the weekend to play.
- When a disc is not supported (or even if it is, but is having decryption problems), a button in the app itself to automatically submit the AACS, CLIPINF, and PLAYLIST data, along with comments of the disc
- When you’ve been throttled (due to hitting your limit with the trial version, or daily limit of the full version), continue to at least give feedback if the currently inserted disc is supported or not. With non-trivial collections, it’s frustrating to take multiple days just to build your to-rip stack. This includes that the feature above should continue to work (submitting the info from unsupported discs), even if you’ve hit limits.
- Improve the install/upgrade process. On first install, there’s no indication that a reboot is required. On upgrade, the old version is left installed. When removing an old version, the new version becomes broken on next boot. The only way I’ve currently found to do a fully clean upgrade without leaving around cruft is to install all current versions, reboot, install the latest, reboot again.
- Minor UI fixes: when the DeUHD window is open, you cannot right-click on the tray icon (to exit, to begin a rip, etc.).
Other than those things, I’m extremely pleased with the software. Sure the ripping speed is slow, but it works. Supposedly that should improve with tomorrow’s release. And sure the supported catalog is small, but three weeks of solid improvements there has me very optimistic, especially with a track record of fixing problems with currently supported discs (the martian extended as an exception apparently).
Well, they’ve improved the install/upgrade process slightly. They specifically call out to uninstall the old version and reboot before installing the new version. And after installing 184.108.40.206, I did not need to reboot before it would recognize my drive.
When I uninstalled DeUHD before installing 220.127.116.11, I noticed that Windows showed uninstall entries for every previous version I had installed. That ought to be changed such that there’s only one entry for DeUHD. I was able to uninstall all of them just fine, as best I can tell. Still, it’s not ideal.
Would love to see an option to disable DeUHD rather than shutting it down completely. Recently I went to process a Blu-ray with AnyDVD the scanning failed due to an issue with the hash. Apparently, DeUHD had gotten in the way of the process. Exiting DeUHD rectified the issue but it would be nice to not have to do that.
For me the “Rip” button (after Rip to Had Disk) does not work all the time. I just end up using explorer
They need to also improve the quality of the Rips - Currently, I have to double rip every disc then compare the contents to see if they are the same. Most of the time there are differences in the files, so I have to rip at least a third time before I have a good rip where the contents match.
This is surprising to me. I have not once had to double-rip. It either works, or it doesn’t – no matter how many times I retry the corrupted files are still corrupt. What drive are you using?
I have two drives - BH16NS55 and BU40N (it does not seem to be drive dependent). I only started doing this when I noticed some playback errors on one of my first rips. I now dual rip, then do a “File Content” compare using FreeFileSync then re-copy any files that are different till I get a match. As an example I’m onto the 4th copy of the main WonderWoman M2TS as so far they are all different (this is the first time I’ve had to do it 4 times), eg here is their MD5’s:
Wonder Woman : cde3d5f26f8939cf69bab73a5be5c09c : Rip1
Wonder Woman : 1012f9961e6d21a23df113011336ed5c : Rip2
Wonder Woman : b76369c4180d745ee01f0e2dfe7fdf4a : File Copy 1
Wonder Woman : 14e31f62ae67377107a20005fb1e499d: File Copy 2
Keep in mind that many of these difference may not greatly impact playback (you may see a “glitch” at some point, but I’ve had errors significant enough that it stopped playback). Regardless I want a 100% good copy not just one that “works”. I’ve also once had errors on some of the smaller files but it is normally the large M2TS (well it is 90% of the disc).
Also - this is why I started the “Verified MD5 Checksum thread” so users can simply check if their rips match the same bitsum for a title (and hence only re-rip if it is different). Maybe this info could be included in the Google Docs.
Do you remux to MKV? If so, does it succeed for both good and bad copies of an M2TS? My experience has been that MKVToolnix will hang on a corrupted M2TS (because it has to actually parse out the data, instead of just copying bytes), and thus have been simply remuxing directly from disc to avoid copying the data multiple times, relying on the remux failing to detect problems. Of the movies I’ve watched completely since, I have not seen any macro-blocking that would be indicative of only a small part of the stream getting corrupted. It seems highly unlikely that random corruption would hit only the HEVC stream, and not any of the TS headers that encapsulates it. Also, like I said, the corruption problems, when they occur, are repetitive for me - the per-block decryption key is wrong. The problem your describing is almost as if your drive is returning different data each time it reads. Which shouldn’t be a thing - all optical discs after audio CDs include error correcting codes so that you’ll know when you read something wrong, and often times can correct it. Audio CDs didn’t have that, and thus AccurateRip was born as a database for people to know if they ripped tracks correctly, similar to your requests for MD5s of the main title TS.
(Btw, my drive is a WH16NS40 SVC50 - the one that doesn’t officially support UHD and AACS 2.0, and I can’t use to play encrypted discs in PowerDVD, but works with DeUHD, and once decrypted, PowerDVD will play discs just fine).
I don’t remux (I keep and play the full Structure - the latest LAV Nightly support UHD BD Structures). I’ve also had one instance where it was a non-video file that was different between rips, but as the vast majority of the data is the video/audio payload it would make sense that this is where it would occur. When I first came across this issue I did tests between both drives and it is not drive related. It could be issues with my PC build (brand new i8700K OC’ed to 5ghz increase rip speed) though I guess the only way to tell is if someone else rips the same disc and few times and then compares the content and see if they also have rip differences on any of the files. I simply use FreeFileSync Compare function (with Comparison Settings = File Content) over the two ripped directories . It is quick and gives you a list of any files that don’t match.
I’ll see if I can find time to re-rip wonder woman a couple times tonight, just copying the main title m2ts. Then I’ll post md5s for you.
I gotta see for myself now. Going to rip WW twice right now. I’ll report back results.
Thanks - FYI, my WW is the Aus version (in has a Japanese Audio/Sub track) that is not on their list (but started working a couple of days ago) so it will have a different MD5 to yours. That said, It would still be very useful to know if others are seeing exact bitsums over multiple rips or if it is just me with rip differences.
4th rip just finished and a different checksum again. Rebooted my PC and started a 5th. If this is still different I’ll try a different PC with the USB drive and see how that one goes. Edit - this was was 14e31f62ae67377107a20005fb1e499d