SACD Ripping using an Oppo or Pioneer? Yes, it's true!

[meega]

Greetings! I am late to the party and since it's not feasible to read through thread with over 200 pages, I very likely will make comments for things that were already discussed in the past in one form or another. So, anyway, as someone that is always interested how the things are made and why are made in such way, I want to ask about the history of this method:

 

1. it's closed source tool contrary to open source 'sacd-ripper'/'sacd-extract', correct? even it re-uses 'sacd-extract' as its base. do you know why it was made closed-source? I have a speculation on that, which I will share in my next point.

 

2. strangely enough, it was built with "mediatek-linux-gnueabi" v4.41 as ARM cross-compiler, which as far as I can tell, is not publicly available (correct me if I am wrong!). So, i think, that's why it was made closed-source as it was assumed the general public cannot build it from the source code. that suggests to me the author is some "insider" and by that I mean someone that at least has access to those not-publicly-available tools, like v4.41 of "mediatek-linux-gnueabi" ARM cross-compiler. if it was released as source code that it will draw immediately attention that whoever made it has access to not-publicly-available compiler required to build it. At least that is my wild speculation...I could be totally wrong though.

 

3. the above 2 are even more strange, considering the fact that since 2012 (i.e. 3-4 years before this was made, assuming it was made around 2016 as when this thread was started), the newer version 4.51 of "mediatek-linux-gnueabi" was already publicly available as part of Western Digital effort to comply with GPL license for their "WD TV Live" player device based on the same Mediatek ARM SoC generation:

 

https://support.wdc.com/downloads.aspx?p=161&lang=en

 

So, that's how "outsider" like me thinks and does - googles for mediatek-gnueabi cross-compiler and the only one that pops out there is v4.51 that WD released and not v4.41 used to build this tool. It's even further very strange choice, because if you go to:

 

https://oss.sony.net/Products/Linux/common/search.html

 

and download the kernel source code for your BDP player, which Sony, as WD, were forced to make publicly available due to the GPL license, you will find README file inside saying respectively for their ARMv6 and ARMv7 devices:

Quote

"The toolchain used is armv6z-mediatek451_001_vfp-linux-gnueabi"

or

Quote

"The toolchain used is armv7a-mediatek451_001_vfp-linux-gnueabi"

 

BTW, WD released cross-compiler version 4.51 for both ARMv6 and ARMv7, i.e. "armv6z-mediatek-linux-gnueabi" and "armv7a-mediatek-linux-gnueabi" even in their archive they are misleadingly named:

* "armv6z-mediatek-linux-gnueabi" is inside folder called "vfp_4.5.1_2.6.27_arm11-rhel4" and based on that very misleading name someone would assume it's cross-compiler to be run on ARM11 in RedHat Enterprise Linux 4, but immediately inside that folder there is folder "i686", i.e. the files are actually for x86 architecture and allow you to build "armv6z-mediatek" executable files.

* "armv7a-mediatek-linux-gnueabi" is inside folder called "vfp_4.5.1_2.6.27_cortex-a9-rhel4" and again based on that misleading name you would think it's cross-compiler to be run on Cortex-A9 ARM in RedHat Enterprise Linux 4, but immediately inside that folder is again folder "i686", i.e. the files are actually for x86 architecture and allow you to build "armv7a-mediatek" executable files.

 

Bottom, line is that WD files plus Sony kernel from the links above give you everything necessary to build any tool for your Mediatek-based (Sony or even other brand) player, they are newer version than what was used to build the tool for this method plus they are publicly available. It all makes no sense to me, at all, why the tool for this method was build the way it was build - again, if we are not talking about some insider having access to v4.41 and thus don't care what is publicly available.

 

4. I know, at least one user here "mindset" is aware of the general architecture of the tool, because "mindset" made post in this forum:

 

 

 

explaining about "sacd_read.ko". So, the method uses modified 'sacd-extract' that loads "sacd_read" kernel object. All useful work is actually done by "sacd_read.ko", that's why it baffles me why at all 'sacd-extact' was re-used. I mean as far as I can tell that gives the following functionality:

 

4.1. network access, which at least to me is useless and pointless, because you need to be physically next to the player to insert disc and then it's just more convenient to connect USB storage device locally

 

4.2. nice name of the ISO, instead something general like "dump.iso". However, that in fact is huge disadvantages in my eyes for 2 main reasons:

 

* giving those nice names is essentially inheritance from 'sacd-ripper', because it operates on "Scarletbook"-level, i.e. on file-system level, instead on Physical-Sector-level as it's best to do for any disc-dumper. the only reason for that is (it was discussed as part of the issues in the original "code.google.com" web-page of sacd-ripper project) that in PS3 it's not possible (or it's unknown) how to tell if particular Physical Sector is Encrypted or not (not all sectors on SACD disc are encrypted). That's why 'sacd-ripper' uses Scarletbook-file-system to get which sectors are occupied by the Stereo and Multi-Channel area and (wrongly) presumes all of them are encrypted. That leads to problem documented in other thread in this very forum:

 

 

 

when you need to modify 'sacd-ripper' for some discs in order to reverse that presumption.

 

* the other disadvantage, I already mentioned in the above paragraph, i.e. work on logic-level, i.e. file-system-level, rather than on raw physical-sector level.

Further more "sacd_read.ko" taps and reuses even the kernel functions to read the disc, instead implements its own functions for that and thus be able to write proper log file and make sure there are no errors during reading of the raw physical sectors from the disc.

 

5. Bottom line, is all it's done in way not to my taste, that's why I took out 'sacd-extract' from the picture and make my own client for "sacd_read.ko" - that relieves all of the issues/things I don't like. Anyway, my alternative client is using raw SCSI commands to control the optical disc drive directly, that's why via SCSI commands it can even gets the device name. Here is how the logs it writes look like:
 

Quote

 

[LOG] Kernel IO Memory Read & Write is successful!

[LOG] System: MTK 8560B             8888
[LOG] Drive : MTK 8550KF1500      85501500
[LOG] Drive : Loading tray...
[LOG] Drive : Disc load time was 2.40 seconds.
[LOG] Drive : Disc profile is    DVD-ROM.
[LOG] Checking if the loaded  DVD-ROM has:
[LOG] "Pit Signal Processing-Physical Disc Mark"
[LOG] yes, it has...SACD disc present version: 0
[LOG] Dumping Physical Sectors...
[LOG] No Errors.
[LOG] Dump completed in 14.85 minutes.

 

 

So, if there is interest, I will release it as open-source tool, but you still need to extract and use "sacd_read.ko" as user "mindset" explained in the post I mentioned earlier. Just for completeness to mention - errors are ultra rare, but they did happen (I guess it depends on the shape of your disc and also the shape of the laser and the optical drive in the player) in such case in the log you get message "Expected Sector number xxx, but got yyy". In any way, I think having log than pure "blackbox" approach is much better, but who knows... maybe it's just my paranoia...

 

[meega]

1 hour ago, Phthalocyanine said:

I do not have the technical background to grasp everything you are saying here...

yeah, it's a long post, but still it cannot explain everything in full details and easy to understand, that's why it requires some technical background, no doubt...

 

anyway, in the mean time as general user, what you can do is grab all 4 files from:

 

https://support.wdc.com/downloads.aspx?p=196&lang=en

 

I already noticed that I got confused even myself by very close names, because now I realize that in my initial post I posted a link to "WD TV Live" files:

 

https://support.wdc.com/downloads.aspx?p=161&lang=en

 

when I meant "WD TV Play" device, which is the one that is MTK SoC-based:

 

https://support.wdc.com/downloads.aspx?p=196&lang=en

 

So, grab the 4 files for "WD TV Play" - they are quite large, 3-4GB in total. Also, grab the  kernel sources for your BDP compatible player from:

 

https://oss.sony.net/Products/Linux/common/search.html

 

I don't know if other brands of compatible players released their kernel sources (even they are obligated under the GPL). In any way, you need at least 1 kernel source for ARMv6 and one for ARMv7. I own S5100, which is ARMv6. So, nothing is done for ARMv7 - sorry if I already disappointed all ARMv7 device owners...