[Device Report] HL-DT-ST BP55EB40 (EB52) crossflashed to omnidrive BU40N

mirh

### Version 6.0.0-beta.1 ### Which operating systems have you used? - [x] Windows - [ ] Linux - [ ] macOS - [ ] Other ### What is the architectural bit size you're using? - [ ] 32-bit - [x] 64-bit - [ ] Unsure or unknown ### What processor are you using? - [x] An Intel or AMD - [ ] An ARM or Apple Silicon - [ ] Unsure or unknown ### Description [The report](https://github.com/user-attachments/files/30156348/HL-DT-ST_BD-RE.BU40N_1.00.json) ### Exact command line used `aaru device report G:` ### Additional info Am I supposed to still get `Using SCSI READ (10) command.` when dumping instead of raw omnidrive reading?

claunia

DO NOT DO DEVICE REPORT OF DRIVES FLASHED TO OMNIDRIVE

mirh

If it was better documented.. it would be nice. Aside of that, any idea why raw bd dumping doesn't trigger?

claunia

Did you use `--raw`?

mirh

\*sigh\* No, as that *also* wasn't documented anywhere. Though it worked. Thanks.

claunia

`aaru --help` it is documented there. that's more than enough for softtware that is FREE OPENSOURCE and you paid NOTHING for using it. Enough documentation for you?

mirh

Ok, lol, the problem apparently was just that I was only [looking](https://www.aaru.app/media/dump.md) at the one on the website. Btw is aaruformat the only one (if I had to make another criticism it is that the formats help doesn't explain to you the extensions corresponding to each label) that supports negative sectors?

claunia

Yes it is, pirates were not interested in saving the lead-in when they created the other formats.

mirh

Enlightening, thank you. Is it possible to store everything uncompressed though? Like, I see a `compress` option available, but non user data blocks (aka any information that isn't in the normal data zone that any iso has?) wouldn't be affected. And idk how I could browse the plain lead-in and lead-out, even with a hex editor.