On Saturday, I received the LG WH14NS40 Blu-Ray Writer Drive. This is my 3rd Blu-Ray writer and it will replace my LiteOn iHBS112 which was causing several bad burns. The other drive is the Panasonic UJ-260, which is a slim drive that burns discs successfully.
This drive is one of the cheapest Blu-Ray XL writers available on Amazon. It is also able to read and burn CDs and DVDs.
Here, we will see the drive unboxed and teared down.
The drive came in this simple box:
There’s no branding. Just a box with the part number printed on a label.
Opening the box we see the drive:
Just the drive. No cables or software are included.
The drive is protected in bubble wrap:
Also also comes inside a plastic bag:
Taking it off we see the drive itself:
Now, let’s take a look at the top, where we will find some useful information:
The drive is the WH14NS40, with SVC code NS50. It was manufactured on January 2020 and comes with firmware 1.04:
Finally, this is the drive with the tray opened:
We will begin the teardown by removing the 4 screws on the bottom:
We can then remove the bottom cover:
Let’s take a closer look at the drive chipset:
It is using a MediaTek MT1959HWDN chip.
Let’s now see the Eject Button, LED and Tray Motor board:
A look at the bottom tray mechanism:
The internal tray loading mechanism and Optical Pickup Unit:
A closer look to the Optical Pickup Unit:
And finally, here’s how the drive looks in my Desktop PC:
This Blu-Ray writer can be crossflashed to the WH16NS60 16x variant. In fact, that was the first thing I did.
The drive is identified as HL-DS-ST BD-RW WH16NS60.
Here is the drive capabilities according to ImgBurn:
So far, I was able to successfully burn a BD-R with media code RITEK-BR2-00 and a BD-R DL with media code RITEK-DR3-000. Both discs were burned with ImgBurn and verified successfully.
Look forward as I test Blu-Ray media with this drive!
In the past few days, I brought a LiteOn iHAS524 C DVD drive on eBay. This drive is quite rare and was being sold as used, but the unit seems to be in good conditions.
The reason to have this drive is due to its unique LabelTag feature. This allows you to create labels on the data side of a CD-R and DVD+/-R. It, of course, will consume space, but the advantage is that you don’t have to manually label the discs as long as there is enough storage. It can also be created as soon as the data is burned given you use Nero Express with the LabelTag software present.
I also currently have the LiteOn iHAS524 A, which had its optical pickup unit replaced with the one used in the B revision. They are compatible with the A units and have been working great. However, the C unit laser is NOT compatible with the A unit, and I guess the same is true with the B units.
Here, I’ll present you with a side by side comparison of the internals as well as its exterior photos.
LiteOn iHAS524 C External Photos
We start with the front of the drive:
As is usual with DVD drives, you get to see the CD and DVD logos; and because this drive also features LabelTag, it has the logo in the front too.
Here is a closer look at the top:
And the back:
This C unit was manufactured on August 2012.
LiteOn iHAS524 A Exterior Photos
Now, let’s take a look at the exterior photos of the iHAS524 A. This drive has been with me since its release in 2010, so it doesn’t have the same condition as the iHAS524 C:
Again, we see the CD, DVD, and LabelTag logos.
Here is the top:
And the bottom of the drive:
It has a missing screw which I lost some time ago when I replaced the drive optical pickup unit. This drive was manufactured on June 2010.
Here, we will see the internals side by side. We will start with the top cover interior:
Now, a look at the drive’s inside:
Both drives looks almost identical, with a few diferences.
This is the iHAS524 B Optical Pickup Unit. The part number is SF-DS1XD. It is compatible with the LiteOn iHAS524 A and is the one it’s using.
And here’s the iHAS524 C Optical Pickup Unit:
The part number is SF-DS1X1. It doesn’t have the small potentiometer on the lower left. Other than that, it looks almost the same.
The back also looks similar. The board from the A model is a bit bigger than the C model.
Here, we see both drives internals with the disc tray opened, giving us a better look at the reader mechanisms.
Unfortunately, the iHAS524 C Optical Pickup Unit is not compatible with the iHAS524 A. The drive refused to turn on, but it seems that what really happened was that there was a short circuit. This caused the ribbon cable to burn:
The iHAS524 A didn’t suffer any damage other than the burned ribbon cable. The SF-DS1X1 laser didn’t get damaged and the iHAS524C was able to work fine. After I made sure it worked, I placed its ribbon cable to the iHAS524 A and it started working with the SF-DS1XD OPU again. Phew!
Long story short, the SF-DS1X1 OPU is not compatible with the iHAS524 A. Use the SF-DS19L (The one that should be used in the A revision) or the SF-DS1XD (For B units, but also works with the A units).
This is the SF-DS19L Optical Pickup Unit which I replaced with the SF-DS1XD:
If you need one of these Optical Pickup Units, you can find them on AliExpress.
Over the past few days, I worked on porting the PAQ8PX compressor for ARM CPUs. Initially, it would not compile because it relied on some SSE instructions that are not available on ARM. This required porting some code to equivalent functions in this architecture. Once this was done, paq8px happily compiled and ran on the Snapdragon 845 and 865 CPU’s from my Samsung Galaxy S9+ and S20 Ultra smartphones:
I tested it using the Termux app running Ubuntu from the AndroNix project.
The changes that were done to make it compile mostly involved adding some #elif directives. These were added below the initial #if directives that checked if we were compiling on i386 or x86_64 architectures. This #elif directive checks to see if the platform is ARM. The reason is that the header immintrin.h doesn’t exist on ARM. Instead, we need to include arm_neon.h and make the appropriate changes to convert the SSE/SSE2 instructions to NEON.
There were 2 main files that had SSE2/SSSE3 instructions that needed to be ported to NEON. In reality, these ports were not needed, as PAQ8PX contains code that doesn’t depends on the instruction set, but porting it makes the software take advantage of the CPU to its potential.
I started by doing the changed to the Mixer.hpp file, which had code for SSE2 and AVX2.
After porting the code, you can see 2 new functions along with some SSE2 to NEON helper functions were added:
SimdMixer.hpp and MixerFactory.cpp needed some additional else if and some additional conditions in order to support the NEON code:
The other file that contained SSSE3 instructions and needed to be ported to NEON was Bucket.hpp. I also did a mayor refactoring to let the code which SIMD to use according to the system spec or the user-specified SIMD to use:
Ported the SSSE3 code to AVX2:
The SSSE3 function is now called findSsse3:
And here we have the NEON code:
If no SIMD is specified or detected, the code will run findNone:
Finally, here’s the find function. It was extended to accept a second argument indicating which SIMD to use:
This change required adding this second argument to the corresponding lines of ContextMap.cpp and ContextMap2.cpp.
This file required adding some #ifdef defines:
Then, I’m returning the value 11 if we have compiled paq8px on an ARM processor:
Finally, the paq8px.cpp file was updated to accept the NEON argument when using the -simd parameter.
And those were the main changes done to paq8px.
Currently, the latest version v187, which completes porting the SSE2/SSSE3 code to NEON, and fixes some bugs from previous versions.
You can follow paq8px development on the encode.su forum by clicking here.
This release changes some encoding flags that will soon be deprecated, removing some warnings that were being printed on the screen, and making it compatible with the latest releases of the SVT-AV1 encoder.