Questions about LEARNING behaviour of Liteon writers

Hi there,

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 :slight_smile:

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 :iagree: ] 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 :slight_smile:

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 :bow: 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 :rolleyes: , 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 :wink:

(f) I have a special interest (and you too :iagree: ) 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… :wink:

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 :iagree:

Best regards,

40tacos

Well,

Despite the fact I had read a lot in this forum…, it was not enough as I can demonstrate myself… Well, this kind of assertions is always true for anyone in any area of human knowledge :slight_smile:

Hence, I explicitly admit there are ‘flaws’ in my questions (due to my ignorance), but anyway, I hope someone can give me some clues; for example, simple links to this forum, given it’s huge…

I keep reading several threads, as those written by pickles :slight_smile:

Best regards,

@40tacos

I too am quite interested in understanding the mechanics behind how the ‘learning’ process works. In the ‘quality tweaked firmware’ thread, CodeKing actually said he had ‘proven’ the learning behavior and that it took place over the first four burns. I posted a query similar to yours in that thread, but it has yet to be answered.

Hopefully someone in the know will shed some light on it for the rest of us, as the information that is out there is very vague and fragmented.

Thank you for your interest too :slight_smile:

I keep reading…

Just 2 hours ago I ‘fell down in the right tunnel’. Yes, it’s dark and tilted down, but signalled with ‘warnings’ :cop: , so we must walk with care, to avoid a bad ‘slip’. The big / normal / well illuminated tunnel is the robust FIRMWARE (around 1MB); the dark tunnel is the fragile EEPROM (around 1KB). Both memories can be independently changed with the right tool (*.1.2.4).

Well, for 99,9% of people reading this forum, the right decision is forgetting the dark tunnel. I consider myself among the 0,1% due to four reasons:

  • I have read some ‘policies’ around… I beg God pardon if miss someone important :bow:
  • I’m an ‘old’ electronic engineer :bigsmile:
  • I can permit myself to experiment and lose 100$ buying a new DVD-burner
  • I’m honest enough not to RMA a drive I could ‘toasted’ (this won’t be the case :wink: )

Next comments will be more technical; meanwhile, I’m looking for again some comments about the location of 4-common-buffers… starting at C0 hex, if I don’t remember badly.

First warning (explained by example): I have an 811s drive; my neighbor has the same model too (811s). Then we can interchange firmware versions; it’s all right… BUT, we should not interchange eeprom’s. Your particular eeprom has information of your particular drive unit; it should be considered ‘unique’.

So, we must go down the eeprom tunnel with our own eeprom backupssss (plural). Only some fileds can be edited, with care… again.

This will continue… I hope

Best regards

Hi there,

I’ll put here as NOTES some of the interesting fragmented info I have read around… so the chain clues/questions/clues arise faster :slight_smile:

My apologies if I’m doing something considered incorrect writing this down; this is only oriented for qualified people. I recognize and appreciate a lot the work and interest of all ofo tou, specially the ones related to omnipatcher.

NOTE 1:
Originally Posted by C0deKing
(2 days ago, “Re: Quality-patched 832S firmware…”)
@all
“Yesterday I proved that the Liteon does learn how to burn the media. This means the first disc can be a poorer result and the second to fourth disc will usually be a lot better. It’s not a single learn for all media but every different media code. This also applied to RW. So it’s important to do 4 burns of the same media, one after the other, to obtain the best results from that particular media. What is also interesting is the drive is pretuned for the type of disc they provide with the drive.”

NOTE 2:
Originally Posted by C0deKing
(3 weeks ago, “Re: The great liteon recalibration.”)
“The only numbers that matter, in your EEPROM, are the ones between C0 and FF. The other changes are diagnostic results and can be ignored” [referring to 80-BF]

NOTE 3:
Originally Posted by code65536
(2004-07-22, “Re: how liteon eeprom and firmware work?”)
"Please make use of the search function. This has been discussed many times before. The EEPROM contains a lot of information. Calibration data (should never change), RPC information (should change), a 16-byte randomly-generated security key with a checksum of this key (should not change), a rotating burn counter, a rotating disc disc recognition counter (3S only), and a debug log of the previous 4 burns (this is the 60+ bytes you’re talking about), and other things that not much is known about (may or may not change). Firmware flashes do NOT change anything.

Once again, the end-user should never have to even touch the EEPROM! Just pretend that it doesn’t exist and let it do its thing. Don’t mess with it, and it won’t mess with you."

NOTE 4:
(20 hours ago,“Re: LiteON SOHW-1213S doesn’t burn DVD”)
Mr.Pikle and the_hetster have an interesting experience with Liteon learning behaviour and workaround to tune it up in a particular case, without touching directly the EEPROM, but being aware of its existence.

Questions in the next…

Hi again,

NOTE 5:
“Dynamic Optimum Power Calibration” is something we should be aware of.
(http://www.cdfreaks.com/article/44/5)
The article is a bit old (may 2001); I don’t know if it extrapolates completely to DVD discs or how it relates to EEPROM / learning behaviour… yet

Warning 2:
I don’t know how deep the eeprom differences are among Liteon models (811s versus 812s versus 832s versus 1213s, …). By the moment, I pressume the zone of interest may be common C0 - FF and a bit beyond.

MY TEST 1:
Liteon LDW-811s (Win2k-SP4, AMD XP 1700+, DMA on, of course)
Disc test: DVD+R RicohjpnR01 (Brand Fuji), 4x, multisession (*pikle tip)
other disc: DVD+RW RicohjpnW11 (Brand Fuji) 4x
811s firmaware: HS0K, omnipatched (recommended write-strats + …
OptodiscOR4@ProdiscR02
RicohjpnR01@RicohjpnR02 (the one I’m interested in right now)
Sony@Sony4D1

a) Flash firmware back from Hs0Q-omnipatched to HS0K-omnipatched
b) Read/backup my EEPROM using Liteon falas utility (v 1.2.4)
c) Burn 3 times DVD+RW @4x and check EEPROM. Result = no change at all !!
d) Burn 1st time DVD+R (0,4GB only) and check EEPROM: it changed as *.png
e) Burn 2nd, 3rd time same DVD+R multi-sess disc: EEPROM does NOT change

This is only my 1st. OBSERVATION of the so-called ‘learning behaviour’ of MY 811s liteon writer. As you can see, only position “FA” changed in the main zone (regarding C0deking info); 80-BF zone will be disregarded, assuming it’s debug zone (regarding C0deking again…); the pictures will be there in any case. Finally, position “11C” changed too, though a bit ahead from the main zone.

Hypothesis 1: FF values (in the zone C0 - FF) seem to be the reset value.
Hypothesis 2: These 64 bytes can be related someway to the mediacode list we can see in omnipatcher (regarding above C0deking NOTE 1 or 2). But 64 bytes seems to be ‘few’ bytes for a two hundred (or so) long mediacode list. So…
Hypothesis 3: The secondary zone (100-1FF) could be related to that big mediacode list… or may be one of the fragile EEPROM zones we should never touch :bigsmile:

I hope I can attach a couple of images; I’m naming my eeproms as… “EEPR_k01.bin”, k02, k03, … watching how it changes uopon burning discs.

This will follow. I expect feedback from all of you and blending info; 1 KB long info can not be converted to TNT so easy… :wink:

Pic1 (k03: before change)

Pic2 (k04: after change, due to 1st. multi-session burn, only)



I wiil post the progressive ‘bad’ (rather ‘sad’) burning quality of the multisession-disc… It seems this litey learning thing is like a 1 year-old clumsy boy starting to walk, breaking first some glasses and fragile jars before a smile can be grasped from his/her parents :bigsmile:

First session = 400 MB, approx.


Second session = +700 MB, approx.


Third session = +900 MB, approx.


When strategy swapped, does it combine all swaps on the destination strategy when learning, or does it learn seperately on the original codes.

And since it surely hasn’t got enough EEPROM for all the codes, does it discard the learning if you use several different medias?

@40tacos

Bytes 0x100 thru 0x10F should be ignored as they have absolutely no effect on burns whatsoever. They are bytes related to the EEPROM checksum.

Some clarification for you… first, byte 0x11C (one of the bytes that you said changed) is a rotating counter. It ranges from 1 to 4 and will wrap back around to 1 after it passes 4.

@All

There is more to be said about this, but I’ll let C0deKing do the explaining, since he’s the one who discovered the details of how the learning works, and since he’ll have a better idea of how much he wants to have said publicly. :wink:

any hope to edit the “learnt” data manually, eg help the drive with learning?;p

Or make the learning a little smarter?

I have my doubts about that one, because i guess these will be eeprom related and therefore unique - Same way you can’t use the eeprom of one drive in another.

Question arising is: What approach do other manufacturers drives have towards this problem. If it works for them without this “learning” tricks, why can’t LiteOn do the same? And what good for are the media codes/write strategies if the drive still needs to “learn” the media?

Thank you all for your interest, information and smart questions !!

(I hope I can post synchronously; I beg your pardon if I don’t)

@All:
By the moment, given the few data I have, I’m only doing the 1st.
pseudo-scientific step, i.e., OBSERVATION, and GATHERING info from
different sources.

And SHARING info, so I can RECEIVE :slight_smile:

I’m moved by curiosity, believing both Liteon and users would benefit.
The main GOAL would be practical RULES for getting better burns (0,1%
wise users would edit partially the eeprom to ‘speedup / workaround’
the learning process; 99,9% other users shouldn’t do that but follow
smart proven recommendations).

@QQuxa:
Your are direct to the core: I want that too !. So I hope the GOAL
exposed above would satisfy you (0,1% :slight_smile:

I won’t rush to an edit, but changing back 0xFA position to 0x29
(or 0x28 :slight_smile: could be a try, given the PI/PO yaw to bad side :wink:

@Matth:
Both doubts are good ones. I think we all have similar questions.

@Jaco2k:
I think we could edit some eeprom values, despite the fact they
are unique. The first RULE would be probably ‘EXTRAPOLATE instead
of COPY’ from other users.

Burn process depends upon three factors/engines at least: DOPC (see
above URL), mediacode write strategies (see omnipatcher) and learning
behaviour (see this posts :-).

I assume other manufacturers do really a good job tuning and
maintaining updated its big list of mediacode-dependent write
strategies (I suspect NEC is one of them) and they probably do not
use the ‘learning trick’.

On the other side, I suspect Liteon have a rather poor equivalent
list (less tuned/updated) and laid more in the ‘learning trick’. I
like this engineered solution, but the Liteon results are not so
good, by the moment.

But the industry improves each day…

@code65536
Thank you for sharing the info!! OK, I will ignore 0x100-0x10F. The
counter 0x11C was fair with me, showing the ‘suspicious’ change
0x04 to 0x01 in my first attempt :slight_smile:

@C0deking
I hope you could throw some light and share knowledge. Thank you in
advance :slight_smile:

@All
OBSERVATION 1: They have not changed yet, but 0x11D and 0x11E could
be 2 more sibling rotating counters… in this already used eeprom.

Hypothesis 4 (for example): independent DVD+R,DVD-R,DVD+RW counters
(curiously, I have never used DVD-RW, so 0x11F could be the 4th one,
remaining in a ‘reset’ value of 0xFF).

Hypothesis 5 (0xC0-0xFF zone, at least): 0xFF would be the reset
(unused yet) value.

Hypothesis 6 (same zone,…) : Already used bytes seem to be around
0x40 (44, 3A, 45) in the first half (0xC0-0xDF range). I suspect
they could be DVD-R mediacode related tuning values. Dont know yet…

Hypothesis 7 (same zone,…) : Already used bytes seem to be around
0x30 (34, 32, 29, 2A) in the second half (0xE0-0xFF range). I suspect
they could be DVD+R mediacode related tuning values. Dont know yet…

Warning 3: These values are in MY Liteon writer; don’t know all yours…

QUESTION 1: Who knows about 0x120 - 0x1FF zone ? ANY info / hypothesis
is valuable at this stage of my ignorance :slight_smile: By the way, it should
be clear the words ‘TST2’ and ‘TST1’ and the end of this zone (at the
end of the EEPROM these words are there too). I’m thinking in C0deking
at this very moment and the ‘pretuned’ bundle disc of Liteon, don’t
now why… :wink:

More tomorrow, I hope… Best regards,

Hi there,

PRE-CONDITIONS (results from TEST 1):
Three sessions burned @ 4x, Hs0K-omnipatched as shown above
(400MB + 700MB + 900MB)

MY TEST 2:
Liteon LDW-811s (Win2k-SP4, AMD XP 1700…)
Disc test: DVD+R RicohjpnR01 (Fuji), 4x, same multi-session disc
811s firmware: HS0R, non-omnipatched this time…

a) Flash from HS0K-omnipatched to HS0R-non-omnipatched (no EEPROM change, and this will be always true, as stated by C0deking :cool: )
b) Burn 4th session (0,35GB approx). EEPROM changed! (next *.png)
c) Burn 5th session (0,30GB approx). EEPROM not changed

OBSERVATION 2: This time position “E7” changed from 0x29 to 0x2A.
Counter “11C” advanced.

Hypothesis 8: Position could be different due to to removal of omnipatched write-strategy (different mediacode pointer?)

OBSERVATION 3: HS0R behaves a lot better than my omnipatched Hs0K [at this stage of learning…].

OBSERVATION 4: 2nd. HS0R burning shows slight growing PI/PO: negligible?

Hypothesis 9: 1st. ‘learning step’ is in the opposite direction as we want, as someway stated in other threads.

Four Pictures follow:

-Eeprom main zone before change
-Eeprom main zone after change
-Hs0R scan of 4th session
-Hs0R scan of 5th session

Be quiet: you’ll see later HS0Q and HS0K scans of the same disc…

I’ve done more tests. I’m just sharing my notes. More eyes, more wise.

:slight_smile:

It’s becoming difficult to upload 2nd PNG file…


4th session scan
writing firmware = HS0R
reading firmware = HS0R, same LDW-811s unit…


5th session scan (HS0R)…


Well, I have no enough time to explain it all, but I post some images expecting they are self-explanatory. This is always the very same multisession disc. Next time I will post the ‘C0-FF’ images.

Pay attention to the learning behavior of the 811s aiming at better READING, in the very latest burns (both HS0K): PI/PO values ‘scaled-down’ by a 60%, approx. !!!

Textual details later…