18 December 2017

Today I received a used Xeon E3 1265L from China via ebay for $85. My motherboard is AsRock B75M-GL and originally host Pentium G2020 (was about the same price at that time). This Xeon is lower in wattage(45 vs 60) and has more cores (4+HT vs 2). Sandy/Ivy motherboard was Intel's last generation to properly support XP (my USB3 ports automatically turn to USB2), so I'm grateful to have this processor upgrade. Not just for XP but also for other classic 32bit compatible OSes (OSX 10.6.8, RHEL6, DragonFly BSD 3.2.8 or Solaris 10)

There is an incident during installation, I accidentally scratches the LGA pins and two pins get bent (gulp), When I first boot it, the BIOS tweets 4 times and I was like "Damn I'm done for it!". I spent a lot of time to massage the bent pins using smallest screwdriver that I have with other hand holding flashlight and I hardly break a sweat (cool). Once both looked upward again, the second boot get the system properly detected, temperature is at ~38C so I guess that's good enough for used item.

Now for the first time :

So this configuration: Server CPU + desktop motherboard is a good deal afterall. I understand why used ECC DIMM is super cheap since it's has big compatibility issues, but this cheap Xeon is no-brainer.

BTW the delivery is one and half week late than the max. estimated date.

16 December 2017

I have installed MSYS2 version that works with XP, and Perl 5.22 was the last build to run. In few cases I'd need to use native version e.g. in conjunction with native gnu-make. So I look at ActivePerl 5.22 which unfortunately drop support for XP just at the same version that I need.. heh!

Installing it under MS Application Verifier disguise works well, but damn, ActiveState sure know how to play hide and seek with their installation files lol. No worries! Process Explorer/Hacker will track them down for us.

After trivial tests I don't see any problem with its executables it's not like they try to disallow it to run on XP, seems they just make it not installable. I wonder if more ISVs doing this.

So I remove the "obstacle" in the msi file and pack a 7zip of it.

Note that while Perl is opensource, ActiveState added package manager among other enhancements which make it overall not OSS.

15 December 2017

Since 2001 I have used CD, beyond scratches it's quite realiable, I have hundreds CDs still readable from which I bought between 2001-2007, that's up to 15 years durability and counting. There is an exception: all "GTPro CDR+" brand CDs are unreadable (all of them!), it's single most popular brand in my area (probably in the entire country) and represent about half of all of my CDs. Was it a dumping case? who knows... Good things my conscience say I should not trust just one brand.

Since late 2000's I switched to DVDs and the awful traits just started to crop up just after 5 years period. "disc rot" which in my experience seems only happen with DVD, while in other hand CDs experience crumpling due to unprotected data layer surface (upside) which common on cheap disc, especially in outer region where physical contact often made with tray. DVD instead rot from inside, and it rot badly and visibly, a clear sign that this "backup" media need immediate replacement... duh!

When data is stored in "continous and read only" manner, Knowing the LBA is like knowing the page number of a printed book, the table of content. That the lesson I learned (from isobuster) and unfortunately most cataloging software doesn't store LBA. Why important? because different burning software has different sorting order.

And not just filename order, directory hierarchy also has several pattern order on how LBA then assigned to the files inside (root to child, parent directory grouping to root, etc).
Thus only have filename, size, or even metadata is NOT good enough. Because in the end during the nightmare you'll be like "Which burning software I use to burn that disc?" not good!

Imagine if TOC is not readable "enough" (I said "enough" because there may several TOC available: ISO9660, Joliet, Amiga RockRidge, Mac HFS, UDF etc and having one of supported and not fake one being readable is enough). You're left with huge multiple chunk of readable raw data with 2KB blocksize to recover, and with most type of files being binary you need to figure out header and end header of filetype, which size belong which file and so on, yeah possible as they are sequential... but not gonna do that to a hundred of 4 GB DVDs ain't we?

Recovery Tools
The tool that I use is cdrtools' readcd and isobuster. The latter is to figure out LBA from salvaged TOC, note that TOC not always written inner (lowest LBA) some software write TOC at highest LBA (outer) which most likely worst idea. Readcd is capable of image cloning as well as on-demand sector range copying. Note that isobuster is also capable of unstoppable copying but IMO not as good as readcd, therefor I use the free version 0.99.9, cdrtools is open source.

Note about unstoppable copying in both software:
While isobuster will pause on error via dialog box which then you can retry and continue.
With readcd (a commandline app) you can "force-pause" the pending not-yet-started loop cycle by selecting something (with left click) in the cmd window in Windows 10 or right-click -> select (block) for earlier Windows but you need to monitor the progress. Otherwise you can join readable chunks from sector range copying.

Condition

Unreadable: a disc that might superficially pristine (not even single scratch/rot) but become unrecognizable or before that, have tons of read errors all over area after period of being kept.
Disc rot: mostly happen from outer region to inner and quite visible, has washed out coloration.
Inaccessible: Disc TOC isn't readable "enough", On NT6 drive letter will show but will give error message when you access it
Unrecognizable: Your disc no longer considered a disc, it just some another plastic to your drive. None of your disc area is readable and not just the data area. Here on NT6 Drive letter wont show. So readcd/isobuster can't access it as well. Being uncognizable in mostly persistent and nothing you can do about it but at early stage you can bet your luck.

Dealing with physical damage

Use toothpaste to wash the disc from glued dirt and especially deep scratches. Note I don't know what going to happen to the disc due to detergent, but it always give new hope for retrieval, afterall once I get the data the disc will go straight to the bin.

Dealing with disc rot

Just because the area start to rot doesn't mean it become completely unreadable. Anywhere in the rotten area you could bet your luck to retrieve tiny file of several blocks. Most DVD any brand that I have tend to develop rot at varying degree. Somehow having TOC readable mean good chance of read for the rest data, not so much when TOC not readable that is resort to use sector range copying, of the very same disc but in different recovey session. So don't give up to make the TOC readable first. By average I could recover 3 to 3.7GB of 4GB data.

Dealing with the unreadabledisc

Now here we go the shitty part, the unreadable disc, the worst case scenario. Many remain mystery for me, like how the hell this crap being manufactured and being brand related occurrence. In my experience DVD brand printed as "mitsubishi" is known to be suicidal . From my experience there are several factor involved in recovery chance (of course most of the blame goes to the disc manufacturer):
- proper drive read speed (lowest speed is not always better!)

14 December 2017

FFmpeg itself has no problem with XP, but its dependencies are. This build is feature complete (and therefor non-opensource and not redistributable) oh well.

This build specifically for XP so most of AVX optimization disabled
Aotuv is used for vorbis encoder and capable of ~32kbps at -aq 0
x264 and vpx codec use high bitdepth but not for x265 (is too slow)
your custom fonts goes to fonts sub-directory (via fontconfig)
your frei0r dlls goes to frei0r sub-directory
your ladspa dlls goes to ladspa sub-directory
place libbdplus.dll+libaacs.dll or libmmbd.dll in the root directory if you need those
flagged with LAA (bigmem)