Hi everyone,
Today, I have released Google Drive Uploader & Explorer Tool v1.13:
This version has the following changes:
You can download it on GitHub by clicking here.
Enjoy!
Hi everyone,
Today, I have released PAQCompress v0.3.48:
This release adds paq8pxd v87, v88 and v89.
You can download this new version on GitHub by clicking here.
Enjoy!
Hi everyone,
Today, I have released PAQCompress v0.3.47:
This release fixes the following issues:
You can download this new version on GitHub by clicking here.
Enjoy!
Hi everyone,
Today, I’ll show you the OWC Mercury Pro 5.25″ External Optical Drive Enclosure:
This is an enclosure designed for Internal 5.25″ CD, DVD, and Blu-Ray drives. It uses a USB 3.1 Gen 1 connection to transfer files faster than when using USB 2.0. This mainly applies to Blu-Ray discs since they can have a very high transfer rate when compared to CD or DVD, hence having a USB 3.1 Gen 1 connection allows us to benefit by having faster transfer speeds.
The enclosure comes in a simple box where when opened, we see a box that contains the power and USB cable as well as the screws needed to mount the drive:
We then see the enclosure below:
It comes protected inside a plastic bag:
Once we take it out of the bag, we can see the shiny metal enclosure:
Inside, we can see the board and SATA cables:
I took out my LG WH14NS40 Blu-Ray drive from my desktop so I can use in the enclosure on all of my computers:
Installation was very easy. The drive was inserted and the screws were installed on the sides and bottom. The result is very nice looking portable desktop drive:
Windows 10 detects it as Mercury Pro Optical and lets us know that it is connected via USB 3.0:
So far, the enclosure has been working very great.
Now, I need another enclosure for my LiteOn iHAS524 drive, which is still my preferred drive to read and write CD and DVD.
Hi everyone,
Remember my previous post where I was talking about the LiteOn iHAS524 C and mentioned the different optical pickup units this model use across its different revisions? Turns out that the SF-DS1XD OPU used in the iHAS524 B was having trouble burning DVD+R DL, so I began my search for a used iHASx24 drive from the A revision.
On Friday, I got a used LiteOn iHAS124 A delivered. This model use the SF-DS19L OPU that all LiteOn iHASx24 use (x being a number from 1 to 6).
The LiteOn iHASx24 series are all the same, except that the iHAS224, iHAS424 and iHAS624 has the hardware for LightScribe burning, while the iHAS124, iHAS324 and iHAS524 doesn’t. Other than that, the hardware is identical but they have different firmwares. The capabilities between models are the following:
Basically they have a different firmware enabling LightScribe, LabelTag and SmartErase depending on the model you have. Even if you have a different model, the firmware can be crossflashed by using some tools and firmware. I will not be covering that here, but it’s good to know if you’d like to add some features to your drives. The only feature that depends on hardware is LightScribe.
My LiteOn iHAS524 has been with me since 2010, and it’s probably the best CD and DVD burner available given its ability to overspeed 16x media to 20x. It also has HyperTuning, Online HyperTuning and SmartBurn, which are essential features to burn media with great quality. This is why I still count on this drive as sometimes I like to store data on optical media.
The drive had its optical pickup unit changed to the SF-DS1XD some years ago because one CD broke inside the unit, damaging the original SF-DS19L. I also didn’t use DVD+R DL media, so everything was fine, until last week. It turns out that the OPU had problems burning the discs. Specifically, it had problems focusing on the second DVD layer, failing at 50%. This is why I brought the used LiteOn iHAS124 A drive.
Because this unit is an A revision unit, the hardware between the iHAS124 and iHAS514 is the same. I did changed the iHAS524 disc mechanism to the one from the iHAS524 C revision, with the exception of the OPU:
On both photos, the iHAS524 is on the left while the iHAS124 is on the right.
Here we can see the disc mechanism from the iHAS124 unmounted:
And the Optical Pickup Unit taken out of it:
I’ll be using this OPU in the original iHAS524 mount, so I placed it there:
And finally, here’s the disc mechanism attached to the iHAS524:
The OPU started working immediately. It is now loading discs faster and wasn’t making weird noises. I was also able to burn some DVD+R DL media without issues. I’ll be talking about that on another post, but for now, this is it.
Hi everyone,
Today, I have released Opus GUI v1.16:
This release adds a new text file called audioformats.txt. In this file, you can specify the file extensions that the GUI will process:
You can add new extensions as long as ffmpeg supports it, and they will be processed only if ffmpeg is present. Otherwise, only WAV files will be processed.
This version also has some bug fixes and improvements and updates the Google APIs to their latest version.
You can download this release on GitHub by clicking here.
Enjoy!
Hi everyone,
Today, I have released PAQCompress v0.3.46:
This release adds paq8pxd v86.
You can download this new version on GitHub by clicking here.
Enjoy!
Hi everyone,
Yesterday, I began working on my second collaboration for the exhale xHE-AAC USAC encoder. This time, I worked on adding an argument to print the software version on the console.
The above is the main software, printing its information as well as how to use it.
There was no option to print the version only. Ideally, I just wanted a way to print something like exhale version 1.0.3 .....so that I can easily parse it as I do with other tools like Opusenc and Flac. Because of this, I began working on adding this functionality.
The code that performs this will check if there is just one argument (actually 2, since the first one is the executable filename). It also checks if the argument is either -v or -V. If this is true, we print the software information to the user:
This is the result:
A very simple and minimalistic output. Thanks to this, I can parse it and use on tools like my upcoming exchale GUI:
This Merge Request was approved and merged and is ready to use for everyone. As for the GUI, expect it in the next couple of days!
Hi everyone,
Yesterday, I collaborated on the exhale xHE-AAC Audio Encoder to add compatibility to compile the project on MinGW on Windows.
The exhale project is an Open-Source xHE-AAC USAC encoder. It allows you to encode wave (WAV) files to M4A using this specific codec.
Originally, compilation on Windows was done using Visual Studio, and this worked fine, but when compiling it on MSYS2/MinGW, it gave some issues, specifically:
H:/repos/media-autobuild_suite/build/exhale-git/src/app/../../src/app/exhaleApp.cpp: In function 'int main(int, char**)':
H:/repos/media-autobuild_suite/build/exhale-git/src/app/../../src/app/exhaleApp.cpp:246:85: error: '_SH_DENYWR' was not declared in this scope
246 | if (_sopen_s (&inFileHandle, inFileName, _O_RDONLY | _O_SEQUENTIAL | _O_BINARY, _SH_DENYWR, _S_IREAD) != 0)
| ^~~~~~~~~~
H:/repos/media-autobuild_suite/build/exhale-git/src/app/../../src/app/exhaleApp.cpp:320:100: error: '_SH_DENYRD' was not declared in this scope
320 | if (_sopen_s (&outFileHandle, outFileName, i | _O_SEQUENTIAL | _O_CREAT | _O_EXCL | _O_BINARY, _SH_DENYRD, _S_IWRITE) != 0)
| ^~~~~~~~~~
make[1]: *** [../makefile.base:112: ../../build/exhaleApp.d.o] Error 1
make[1]: Leaving directory '/build/exhale-git/src/app'
make: *** [makefile:18: all] Error 2It also complained about fprintf_s, so some changes needed to be done on the code.
To solve the _SH_DENYRD not declared issue, we had to include the share.h header:
Next, to solve the fprintf_s issue, I surrounded this on an #if !defined block to check if we were compiling on MinGW. If we are, we simply skip this declaration:
After these changes were done, the software compiled successfully.
Next, I did some additional changes to the makefile.base file to allow the Media Autobuild Suite project to pass its CXXFLAGS and LDFLAGS variable to exhale:
These changes got merged into the project.
My inspiration to add this tool to the Media Autobuild Suite came as a user requested this tool to be added to it. So, I worked on it and submitted a Pull Request, where I refined it further to apply some recommendations.
The Pull Request was merged into the suite and is now available for everyone to build and use.
Hi everyone,
Yesterday, I received my very first BDXL media. These are way more expensive than BD-R and about twice the cost of BD-R DL media.
For my first BDXL recordable media, I decided to get the Verbatim 10-pack spindle. These seem to be one of the lowest-priced media when compared to 3-packs or 5-packs variants of other manufacturers.
These BDXL discs are rated at 4x, but my LG WH14NS40 crossflashed to the WH16NS60 firmware detects them as having a write speed of up to 8x.
The Media ID is VERBAT-IMk-000.
On my Panasonic UJ260, these have a maximum write speed of just 2x.
I added files to burn using ImgBurn, and made sure to use the most space possible. I then started the burning process on my WH14NS14 at the maximum supported speed of 8x.
Añadí archivos a ImgBurn y me aseguré de llenar el disco lo más posible. Luego, comencé a quemarlos con mi LG WH14NS14 a la velocidad máxima de 8x.
It seems the drive use a Z-CLV (Zoned Constant Linear Velocity) strategy to burn these discs. The write pattern was as follows:
We can see the pattern below:
Some times, when the writing was at 4x, the drive would go down to 3.3x for about 1 second or 2:
The same happened when the drive was recording at 6x, going down to 5x for a second or 2:
The drive successfully burned this media, having an average speed of 5.7x:
Verification was slower than the writing itself, as it limited the read speed to 6x:
The verification was successful and no errors were reported:
The average read speed was 4.3x, slower than the 5.7x average when writing to it. It also seems that while ImgBurn set a read speed of up to 6x, the drive went all the way to 9x, according to the Maximum Verify Rate.
Here, we can see the written disc with its Z-CLV zones:
These discs seem to be compatible with the LG WH14NS40 Blu-Ray writer. They also burn at a faster 8x speed which is more than its rated speed of 4x. The drive was able to successfully burn them and read them. These discs, while expensive, allow us to write up to 100GB (about 93GB of actual storage) on a single medium. It would have taken us 4 25GB BD-R or 2 50GB BD-R DL media to write an equivalent amount of data.
Unfortunately, I don’t have any BDXL scanner I can use to test the quality, but the media can be read back on the LG drive as well as on my Panasonic UJ260. The latter seems to read the disc in Z-CLV too, but it was able to read the data back successfully too. It is just slower than the LG drive.
If we compare the price of having 10x 100GB Blu-Ray discs to owning a 1TB Hard Disk Drive, we can see that the BDXL media is a couple dollars more:
The BDXL media on eBay (It was at $53.15 at the time of puchase):
On Amazon. They seem to have lowered the price to $49.99 at the time I took this screenshot:
The price of 1TB Hard Disk Drives on Amazon:
Ultimately, it all would depend on your needs. Personally, I like to write data that will not be used frequently on optical media, while having frequently-changing data on the discs. I’ve also had a bad experience of having Hard Drives fail, and while I’ve had optical media fail too (Some bad Blu-Ray batches that deteriorated in a couple of years), the data loss is not as much as losing a whole hard drive. Remember to back-up your data!