Upon reading a lot in this forum, ‘omnipatching’ and doing PI/PO measures, I’d like to know more technical details about the ‘learning’ behaviour of Liteon DVD writers (referred somwhere as ‘memory effect’).
Maybe only omnipatcher experts (Codeking, C64k, rdgrimes, pinto, Qquxa, OC-freak…) could answer to these questions, but welcome any input
I own an LDW-811S and I’ve tested HS0K, HS0P, HS0Q and latest HS0R firmware versions, including codeguys.rpc1.org ‘readspeed-hacked’ versions and my own modifications of ‘write strategies’ using omnipatcher (1.3.x).
[hard-to-answer ] QUESTIONS:
(a) I have read Liteon saves ‘info’ in a buffer about the last 4 burns, or similar. In the case it’s someway true, What kind of ‘info’ does it save?. For example, Does it save ‘info’ in separate buffers, regarding each manufacturer codes / write strategies ?? (or groups, speeds, etc). On the other side, maybe the 4-buffers are common and ‘info’ is only an approach to
laser power calibration and speed zones (?).
(b) Are those 4-buffers always ‘deleted’ each time the firmware is re-flashed ? (so Liteon ‘forgets’ what it learned). Are there cases where that info can be retained someway?. For example, changing from ‘HS0Q’ to ‘HS0Q-rs-patched’ could mean LiteOn wisely preserves that 4-buffer info, given it’s the same base firmware code (HS0Q); I don’ know. From othe point of view, it could be advisable to save your ‘own’ current firmware (asuming it someway include the 4-buffers…!?), before testing a new firmware… Is that possible?
© other questions from yourselves
ON THE OTHER HAND [maybe the big ‘debate’ -open firmware business view- ]
About ‘write strategies’ firmware tables [indexed by manufacturer codes]…
It’s clear enough for me ‘how omnipatcher currently works’, so you can burn a specific -R/+R manufacturer code as being another code (the ‘host’), without affecting the host itself. The questions are:
(d) Is there a way to change (experiment) a specific write-strategy itself? For example, maybe each manufacturer code (eg: optodisc OR4) is assigned a XX-bytes length space, but the exact meaning of each byte/field is not known yet by omnipatcher experts… or maybe they DO KNOW Well, I am all ears… Happy to experiment with a hex editor…
(e) Of course, If someone knows the meaning of those fields (power levels, speed zones, etc) and basic rules to follow , welcome his/her knowledge. By the way, I think if Liteon make it someway ‘public’, the curious users and ‘Liteon defenders’ … would massively tune-up its DVD writers… A win-win (Users win, Liteon company wins). Utopia? This is what I would name the open firmware debate
(f) I have a special interest (and you too ) in controlling someway the write strategy / behaviour at the END of a burning in my 811S (I know ‘fall-back’ is not enabled in omnipatcher for THIS Liteon model, don’t remember why). But may be there is some kind of workaround; or some kind of hex/binary investigation to do in Liteon firmware, I can help with (?). The ideal target: a way to lower burning speed in the last 500 MB of a 4,7 GB disc.
Note: I have observed that selecting 8x speed, LDW-811S (approx) realy burns at 3.9x between 0% and 5%; 6x between 5% and 32%; 8x between 32% and 100% 4,7GB disc (using Nero register-patched). i would like to lower again to 4x at 90%-100%… and I’d like to be rich too…
Seriously, regarding point (e), I really think Liteon would win at this very moment, specially knowing that burning quality of competitors like NEC (eg: 3500) and Pioneer is a lot better by far. I have seen with my own eyes and batch discs (eg: cheapy/crappy Samsung optodisc OR4, badly burned with Liteon) how the NEC 3500 burn them with great quality (about 20-30% of PI/PO values !!). Of course, a Verbatim is well-burned by almost any writer, but low-medium quality media… ah!, that’s the BIG test