Now that we’ve covered the contenders for this test, I will cover how this test will be performed and go through the results. It was a long time for me, but for you, it’ll just be a few hours between posts …
Methodology & Limitations
It might sound simple to experimentally determine how many times a DVD±RW can be rewritten – simply write the disc and read the disc until it fails, but this ignores a few nuances, more specifically, how can it feasibly be done and what do the results even mean.
For this test, rather than write my own software to try to write, read and quality scan a disc, I opted to stick to using Opti Drive Control. Using the software, a test disc can be written and verified, the transfer rate can be checked and quality scans can be performed. The write-verify cycle ensures the disc is at least readable, while transfer rate tests allow for “weaknesses” in the recording quality to be identified based on their impact on the transfer rate. Finally, the quality scan feature allows for the drive to report correctable errors and jitter levels to be able to identify degradation in recording quality before it impacts on the readability of the disc.
But I wasn’t going to have enough lifetime to sit there, click buttons, burn after burn. After all, a 2x burn takes about 30 minutes, and if the disc can survive 1000 cycles – that’d be almost 21 days of burning time alone. A 4x CLV quality scan (my favoured scan rate) takes 15 minutes too, while a TRT and verify added together may take around the same amount of time, assuming the disc is good. So this is a big time investment that demands automation.
To do this, I decided to write my own script using pyautogui. This Python library allows for automating clicks and keystrokes, so I wrote a script that would detect elements on the screen to deduce what was happening and click the appropriate buttons, taking screenshots at the right time so as to capture the results. The script was really flaky at first, in part because I was running on a very old spare computer that was slow to draw the graphs resulting in “broken” screenshots. Furthermore, it seems the theming and styling of Windows is important too, as later versions of Windows may highlight boxes on hover-over, resulting in failed exact-matches for screen snippets. After debugging with a few delays, trying different variants of buttons and building in error-recovery (i.e. sometimes flaky discs just need a “refresh” nudge), I had something ready to unleash on test sample discs.
This leaves the question of which drive I should use for the test. It didn’t take me long, but that old computer I was donated had a practically unused, retail Lite-On iHAS120 6 in it which was a great candidate for testing. This drive supported error scanning with jitter, making it a key asset and quickly became one of my favourites even before I bought a duplicator filled with its cousins. Even better, I had two extra drives of the same model in the collection, so if it should fail, I could carry on the experiments with the spares.
The script would use ODC to write a test disc, verify the test disc, run a TRT on the test disc and then a quality scan. It would loop around over and over until the script timed out on an unrecoverable error condition or I stopped it as it exceeded expectations or had previously had a verification error but was not bad enough to cause the script to fail issuing further rewrites. Specifically, the disc was not unloaded and reloaded between attempts to save wear and tear on the tray mechanism and reduce noise.
Soon, an issue was discovered due to the slow nature of the media meant that it would take close to a whole year to complete testing, so I employed a second iHAS120 6 in parallel – this one in a USB 2.0 enclosure connected to a mini-PC. This ran Windows 11, and was both faster and more power efficient. The script needed to be modified for this, but it allowed for improved test throughput.
One downside of Windows 11 is its propensity to download and automatically install updates, which caused a few interruptions to testing. Eventually, I killed the requisite services and firewalled the machine from the internet entirely, to stem the automatic updates.
... continue reading