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

[Dick Darlington]

19 hours ago, meli said:

 

I just tried again using Disk Utility on a Mac and AutoScript wouldn't run on my Oppo 103 when the USB drive was GUID.  I'm not knowledgeable about this stuff, but perhaps the problem is that when formatting GUID ExFAT,  I always get a child count of two.  When using MBR, I get a child count of one.

 

I'm sure you're right that I'm doing something wrong.  But, at least for me, the easy workaround is to just use MBR.

(Although I'd be interested if you know offhand what I'm doing incorrectly)

 

@meli, I wasn't suggesting that you were doing anything wrong but rather that your conclusion that the Oppo will "see" a GPT formatted disk but is not able to launch the AutoScript from a GPT formatted disk, although perfectly reasonable given your troubleshooting observations, is not actually the case and therefore something else, most likely a hidden system partition was the actual culprit.  I wouldn't even call using MBR a workaround because it's correct and as far as I'm concerned the best way to go.  For that reason, other than listing the Oppo as both GPT and MBR compatible in my media formatting guide targeted to Mac users, the GUI and command line procedures for media preparation are decidedly MBR only.

 

TL;DR for new/uninitiated macOS users:  The SACD Rippers Guide to the macOS Media Formatting Universe 

 

You are absolutely correct IMHO that the MBR is the way to go because it's easy; it is compatible with all the known ripping capable players, which cannot be said of GPT; and the only situation that I can think of where someone would have a need-based motive for using GPT for this application is such an extreme corner case it borders on the absurd.  This is even more true for Mac users given macOS's dogged determination to stick a hidden EFI partition at the beginning of every GPT formatted disk. I was never able to get around that using the Disk Utility GUI.  It's been a while since I was deep diving these things and it's become somewhat conflated.  I thought I remembered being able to avoid the EFI partition via the Mac's command line "diskutility".  Upon revisitation I found that I could not brute force a single partition GPT disk using macOS native facilities to save my life.  I was able to prevail using a low level third party disk utility, but that was just me trying to beat The Man in Cupertino and otherwise completely and utterly pointless.

 

Nevertheless and in the spirit of trying to maintain as accurate a body of information as possible for the sake of those whom will be clawing their way through this Threadzilla in the future, my earlier post was merely to set the record straight with respect to Oppo media format compatibility.

 

When it comes to USB disk preparation, discussion of and conclusions drawn with respect to player compatibility are usually limited to file system and partition scheme and associated pros and cons.  This is unfortunate because there is   one more thing, and it's hugely important and it is a universal requirement across all supported players: the position of AutoScript volume on the disk.  If it is not the first partition, then the AutoScript will not launch and there will be no joy.  This continues to trip people up albeit infrequently.  Unfortunately it is surprisingly easy for someone to end up with a noncompliant USB disk in this regard.  Even if they *believe* they completely reformatted the disk with only a single partition.  And even if it *appears* that there is really and truly only one partition on that disk.  Not everyone would notice as you did that your device had a "Child count" of 2 and/or that the device name was "disk?s2" and not "disk?s1" as it must be to work.  On macOS, that's all you're gonna get from the GUI.  Graphically it shows only one disk containing one volume. This is why I always include wording such as "... and is the first partition on the disk" in the context of USB media preparation.

 

 

PS:

Believe it or not there are a lot of posts containing incorrect information due to innocently ill formed conclusions strewn about in this 140 pages and counting thread. <clears throat ... straightens tie> At least one or two or maybe five or six are my own posts.  My most recently identified personal falsehood is my claim, which I just found to be a boldface lie, is that the partition table ID number of the AutoScript volume must be 1 for AutoScript to be found and launched.  That is not true after all. I just did a test where I took a Mac prepared GPT disk with it's problematic hidden EFI first partition and used Windows to delete the EFI partition.  The AutoScript volume retained its partition table ID of 2, but the Oppo saw it as the first partition and launched the AutoScript regardless.

 

[BluRay444]

1 hour ago, Dick Darlington said:

 

@meli, I wasn't suggesting that you were doing anything wrong but rather that your conclusion that the Oppo will "see" a GPT formatted disk but is not able to launch the AutoScript from a GPT formatted disk, although perfectly reasonable given your troubleshooting observations, is not actually the case and therefore something else, most likely a hidden system partition was the actual culprit.  I wouldn't even call using MBR a workaround because it's correct and as far as I'm concerned the best way to go.  For that reason, other than listing the Oppo as both GPT and MBR compatible in my media formatting guide targeted to Mac users, the GUI and command line procedures for media preparation are decidedly MBR only.

 

TL;DR for new/uninitiated macOS users:  The SACD Rippers Guide to the macOS Media Formatting Universe 

 

You are absolutely correct IMHO that the MBR is the way to go because it's easy; it is compatible with all the known ripping capable players, which cannot be said of GPT; and the only situation that I can think of where someone would have a need-based motive for using GPT for this application is such an extreme corner case it borders on the absurd.  This is even more true for Mac users given macOS's dogged determination to stick a hidden EFI partition at the beginning of every GPT formatted disk. I was never able to get around that using the Disk Utility GUI.  It's been a while since I was deep diving these things and it's become somewhat conflated.  I thought I remembered being able to avoid the EFI partition via the Mac's command line "diskutility".  Upon revisitation I found that I could not brute force a single partition GPT disk using macOS native facilities to save my life.  I was able to prevail using a low level third party disk utility, but that was just me trying to beat The Man in Cupertino and otherwise completely and utterly pointless.

 

Nevertheless and in the spirit of trying to maintain as accurate a body of information as possible for the sake of those whom will be clawing their way through this Threadzilla in the future, my earlier post was merely to set the record straight with respect to Oppo media format compatibility.

 

When it comes to USB disk preparation, discussion of and conclusions drawn with respect to player compatibility are usually limited to file system and partition scheme and associated pros and cons.  This is unfortunate because there is   one more thing, and it's hugely important and it is a universal requirement across all supported players: the position of AutoScript volume on the disk.  If it is not the first partition, then the AutoScript will not launch and there will be no joy.  This continues to trip people up albeit infrequently.  Unfortunately it is surprisingly easy for someone to end up with a noncompliant USB disk in this regard.  Even if they *believe* they completely reformatted the disk with only a single partition.  And even if it *appears* that there is really and truly only one partition on that disk.  Not everyone would notice as you did that your device had a "Child count" of 2 and/or that the device name was "disk?s2" and not "disk?s1" as it must be to work.  On macOS, that's all you're gonna get from the GUI.  Graphically it shows only one disk containing one volume. This is why I always include wording such as "... and is the first partition on the disk" in the context of USB media preparation.

 

 

PS:

Believe it or not there are a lot of posts containing incorrect information due to innocently ill formed conclusions strewn about in this 140 pages and counting thread. <clears throat ... straightens tie> At least one or two or maybe five or six are my own posts.  My most recently identified personal falsehood is my claim, which I just found to be a boldface lie, is that the partition table ID number of the AutoScript volume must be 1 for AutoScript to be found and launched.  That is not true after all. I just did a test where I took a Mac prepared GPT disk with it's problematic hidden EFI first partition and used Windows to delete the EFI partition.  The AutoScript volume retained its partition table ID of 2, but the Oppo saw it as the first partition and launched the AutoScript regardless.

 

Apple is not the only one who uses hidden partitions on their disks, Windows also creates a small hidden partition on system disks when they're installed. Neither of them use these hidden partitions, it seems to be more a matter of  JIC. You are correct about being able to see and access Apple's hidden partition using CLI, you can read from and write files to it, although I've never tried to remove it so, mainly because there was no reason for me to do so. As I recall the GUI doesn't see it at all, even if you enable hidden files, you can only see and manipulate it at the primitive level. CLI command is actually 'diskutil'. AFAIK there is no way to remove Apple's hidden partition at least not with diskutil, closest thing might be to 'merge' it with a second partition; if so, unknown what merging a hidden partition with a non-hidden one would result in, even if it's possible... 

[Dick Darlington]

19 hours ago, Triplefun said:

RUFUS is proven software and arguably the goto option for formatting bootable USB devices on Windows. For example see this Techrepublic recommendation  https://www.techrepublic.com/article/pro-tip-use-rufus-to-create-a-bootable-usb-drive-to-install-almost-any-os/ 

 

@Triplefun, I don't doubt your valuation of the Rufus software even a tiny bit and I promise you that I'm not maligning it in any way.  In fact, like I previously stated, I'm glad to know about it and I fully expect that it will ultimately end up in my disk utility toolbox.

 

I simply wished to forestall a potential if not likely misinterpretation of your post by future readers that might not be nearly as computer savvy as you and many of us are.  Specifically that a third party utility (free or otherwise; proven or otherwise) is necessary in order to prepare a USB disk for the SACD ripping procedure when in fact the native Windows disk management tools handle this basic function perfectly well.  I mean the requirement is for a bog standard single partition MBR disk with one of the three Windows supported file systems.  The FS choice possibly being restricted by the end user's player platform.  Of course in the case of the Oppo and presumably the CA, GPT works just as well even if there is no value added by doing so.  IMO of course.

 

I know you did not explicitly state that third party software is required ...

 

On 8/13/2018 at 12:11 AM, Triplefun said:

the AutoScript directory needed to be formatted with an MBR record (see page 103). This can be achieved on Windows using Rufus

 

... but neither did you state that it was an optional alternative to using the Windows Disk Management GUI or Diskpart CL tool so to me the implication at face value was that non-native software was a necessity (even though I thought it unlikely that that's what you actually meant). 

 

Rightly or wrongly I believed that some subset of people might misunderstand, and some of those people might prefer to know that they can do this without installing more software (that they know nothing about and that they have yet to vet via online research if they're so inclined) on their computer.

 

At any rate, we are not talking about preparing a bootable USB device, which is a whole other animal and I know I would certainly welcome a tool like Rufus to accomplish that sort of task. 

 

PS:  I provided the Diskpart command line procedure due to an inaccurate recollection of problems I had with the Windows GUI many months ago whilst experimenting with two players, macOS and Windows, and a host of ever changing variables.  In other words much of the arcane details became somewhat conflated and I was left with a false memory that the GUI in Windows 10 would only lay down a GPT partition scheme and that Diskpart was needed to convert it to MBR.  Well I got that mostly arse backwards and partly conflated with other issues.

 

My actual experience with Windows using the GUI is:

 

1. If the initial USB drive is MBR, then I can easily delete any existing partitions -- visible, hidden, whatever -- and create a new simple volume formatted with NTFS, FAT32, or exFAT.  The reformatted disk will remain an MBR type having a single partition.

 

2. When creating a new volume the choice of file systems presented by the GUI are NTFS and FAT32 only.  I can't explain.  But if the new volume is subsequently reformatted via the GUI, exFAT is included in the file system picker list. I can't explain.

 

3. If the initial USB drive is GPT AND contains "normal" volumes only, i.e. no EFI system partition, then it's pretty much the same as (1) and (2) above except that the resulting disk will remain GPT.  In fact if it begins as GPT then I could find no GUI means of converting it to MBR although diskpart has that capability.

 

4. If the media was originally prepared by macOS thus having the EFI system partition and thereby unusable for AutoScript (which was MY first scenario being primarily a Mac user), then the Windows Disk Management GUI is not your friend.  At least I could find no way to delete the EFI partition or otherwise wipe the disk and start over.  For that, the diskpart "clean" command was required.  Clean wiped the disk and converted it to MBR allowing a new volume to be created via the GUI or diskpart.

 

I am sure the vast majority of Windows users will be starting with an MBR type disk with or without preexisting volumes.  So basically the diskpart command line procedure I posted the other day is completely unnecessary for the lions' share of users as it turns out.  As long as they take care to delete any existing volumes before creating the new AutoScript volume, then all should be fine and the Windows GUI would be the path of least resistance. 

[Dick Darlington]

1 hour ago, BluRay444 said:

Apple is not the only one who uses hidden partitions on their disks, Windows also creates a small hidden partition on system disks when they're installed.

Yes my limited understanding vis-a-vis Windows is that there are circumstances where Windows exhibits the same type of EFI partition behavior as Apple, however I have no clue as to what those circumstances are.  Is my assumption that this would only come up in the Windows world in the case of USB drives that are set up as bootable devices?  For reinstalling the OS or whatever?

 

1 hour ago, BluRay444 said:

AFAIK there is no way to remove Apple's hidden partition at least not with diskutil, closest thing might be to 'merge' it with a second partition; if so, unknown what merging a hidden partition with a non-hidden one would result in, even if it's possible...

Agreed. I tried my level best to force macOS cry uncle and let me end up with a GPT disk having a single exFAT or FAT32 volume via diskutil just to see if I could (because like you say, there's really no point), but that wasn't happening.  The only way I could do it was to use gdisk and get down into the so-called expert menu and blow away the EFI partition that way.  Again pointless.

 

Of course the good news for Mac users is that as long as they know how to get the Disk Utility GUI "erase" tool to allow them to select Master Boot Record as the partition scheme they won't have a problem.  At least not until something goes wrong with the AutoScript folder or script ?

[BluRay444]

42 minutes ago, Dick Darlington said:

Yes my limited understanding vis-a-vis Windows is that there are circumstances where Windows exhibits the same type of EFI partition behavior as Apple, however I have no clue as to what those circumstances are.  Is my assumption that this would only come up in the Windows world in the case of USB drives that are set up as bootable devices?  For reinstalling the OS or whatever?

 

The only time it is installed is when the Windows Installer is run under the following conditions:

There is no existing system partition on the computer.

The system does no have 3 existing partitions.

There is unallocated space on the disk for the extra partition.

 

Under these criteria, USB drives would never have a hidden partition installed with a real MS Windows Installer because (unless modified) Windows is designed to not install on a USB drive of any kind (and we're talking about the Windows Operating System here, not about installing the Windows OS Installer on a USB drive).

 

Why? Bitlocker requires boot files and Windows system files are on separate partitions, to insure that boot files are not lost due to a format when reinstalling the OS. The partition receives no drive letter to help insure accidental deletion of boot records. Windows System Image Backup will backup the 100mb hidden partition automatically.

 

[Beacon]

I've searched this site for the past hour and cannot find the answer to my question - are either Sony BDP-S5000ES or Sony BDP S1E able to rip SACDs?

 

I have an Oppo 103 so am familiar with the process as far as that machine goes and have successfully ripped many SACDs.

 

Thanks....

[Nevermore]

1 hour ago, Beacon said:

I've searched this site for the past hour and cannot find the answer to my question - are either Sony BDP-S5000ES or Sony BDP S1E able to rip SACDs?

 

I have an Oppo 103 so am familiar with the process as far as that machine goes and have successfully ripped many SACDs.

 

Thanks....

There is no mention of either unit being able to rip. There is a complete list a few pages back.

[MikeyFresh]

3 hours ago, Beacon said:

I've searched this site for the past hour and cannot find the answer to my question - are either Sony BDP-S5000ES or Sony BDP S1E able to rip SACDs?

 

You could always just give it a try using the Pioneer - Sony version of AutoScript.

 

In this case those models are very likely a waste of time as far as pursuing SACD ripping, to the best of my knowledge, neither of them even plays SACD, they are not compatible with that disc format at all.

[BluRay444]

4 hours ago, Beacon said:

I've searched this site for the past hour and cannot find the answer to my question - are either Sony BDP-S5000ES or Sony BDP S1E able to rip SACDs?

 

I have an Oppo 103 so am familiar with the process as far as that machine goes and have successfully ripped many SACDs.

 

Thanks....

They do not play SACD's, ergo they do not have the hardware decoder to rip them. Sorry.

 

[Phthalocyanine]

38 minutes ago, BluRay444 said:

They do not play SACD's

Yes and I don't think they even have USB slots either.

These are very early models.  The Sony BDP S1E is one of the first,  if not the first Sony stand-alone BD players from 2006-2007.

The BDP-S5000ES is the elevated standards version of the BDP-S500 from 2007-2008.

Very solidly-made pieces of equipment back when Sony used to make them that way.

As far as I can tell, the first BD player that Sony made that supported SACD was the BDP-S370, 570 etc. in 2010.  So far only models from the 2012 and 2013 BD model years have been found to be able to rip SACD using the existing exploit software.

[JRODRIGUEZ74740]

I got a OPPO103 And trying to go with my first ripping, I have some doubts. Since the ripping  will be saved in the Mac how is established the connection between the OPOO and the MAC? Could be done with WIFI which requires an usb in the opposite , or since it is said any USB shall be out of the Oppos, I must make the connection via LAN?.

 

[MikeyFresh]

3 minutes ago, JRODRIGUEZ74740 said:

I got a OPPO103 And trying to go with my first ripping, I have some doubts. Since the ripping  will be saved in the Mac how is established the connection between the OPOO and the MAC? Could be done with WIFI which requires an usb in the opposite , or since it is said any USB shall be out of the Oppos, I must make the connection via LAN?.

 

 

The Oppo and your Mac connect and transfer the files via your LAN, either Ethernet or WiFi, assuming you are using the server method of ripping.

[BluRay444]

3 hours ago, JRODRIGUEZ74740 said:

I got a OPPO103 And trying to go with my first ripping, I have some doubts. Since the ripping  will be saved in the Mac how is established the connection between the OPOO and the MAC? Could be done with WIFI which requires an usb in the opposite , or since it is said any USB shall be out of the Oppos, I must make the connection via LAN?.

 

I'm a little confused about the meaning of this statement, "Could be done with WIFI which requires an usb in the opposite , or since it is said any USB shall be out of the Oppos, I must make the connection via LAN", but as MikeyFresh has stated, you can use either WiFi or Ethernet, but in my opinion Ethernet would be the preferred. WiFi can certainly be used but depending on your own circumstance, things like what version of WiFi (A, B, G, N, etc), how far your Oppo and Mac are from your Wireless router or Wireless Access Point, encryption overhead, interference from other wireless devices like wireless phones, microwaves, wireless alarms, light dimmers etc, whether you have nearby neighbors with their own Wireless routers and devices on the same band/channel, how many other wireless devices you have that are sharing bandwidth on your wireless router can all play a part in degrading your connection speed; wired ethernet is faster, more reliable, and can easily avoid sharing bandwidth.

Like you, I have an Oppo 103, and have used it with my MacBook Pro, but generally use it with my jRiver Media Server (Windows) which plays DSDs and SACD ISOs natively, and while jRiver is available for Mac and Linux, I use the Windows version because jRiver's newest developments generally hit Windows first and then get added to Mac and Linux later. With the Oppo, it's really easy to implement once you figure out the few pieces you need, and what a few settings on the Oppo need to be... all you really need is a thumb drive, some files available elsewhere in this thread and an Ethernet cable (should you decide to go with hardwired Ethernet).

 

[meli]

Thanks to the people on this thread, I have successfully ripped my small SACD collection using my Oppo 103.   In the near future, I plan to buy new headphones and the iFi Micro DAC (which decodes DSD files). 

 

But that got me to wondering...  How does the future look for DACs that can decode DSD files?   In 10 years will it be difficult to purchase a new playback device that can handle DSD?   Is it more future proof to transcode the DSD files to FLAC, and is there any audible quality loss if I do so?

 

 

[Triplefun]

No matter what the future of DSD there will always be DSD to ? converters.  As it is I  currently upsample all my audio media, most of which is FLAC,  to DSD in realtime for what I perceive to be a much richer experience. There is also a growing number of sites supporting DSD downloads eg. www.nativedsd.com. 

[servoyguru]

@meli If you are looking at a new DAC, I would highly recommend the ProJect Pre Box S2 Digital, it handles everything, including DSD512 & MQA (https://www.project-audio.com/en/product/pre-box-s2-digital/)

 

[Kal Rubinson]

12 hours ago, meli said:

Is it more future proof to transcode the DSD files to FLAC, and is there any audible quality loss if I do so?

You can always do that, if necessary, in the future.  Or, as I do now, on the fly.

[srrndhound]

7 hours ago, Kal Rubinson said:

You can always do that, if necessary, in the future.  Or, as I do now, on the fly.

Are you storing the FLAC or playing? "On the fly" sorta implies playing. If so, why not just use PCM and avoid the computation of lossless encode/decode? Or is it an interface thing?

[MikeyFresh]

23 hours ago, BluRay444 said:

as MikeyFresh has stated, you can use either WiFi or Ethernet, but in my opinion Ethernet would be the preferred.

 

Absolutely.

[mindset]

Just out of curiosity, I acquired  BDP-6200, BDP-6500, and BDP-6700, and confirmed sacd_extract_160 doesn't work on these units due to kernel incompatibility.  They all allow telnet access via AutoScript though.  I'm surprised that Sony has left the security hole open for many years.  Raw reading (without decryption) of SACD using these units doesn't show any speed improvement over older ones like BDP-S5100 and BDP-S390.

 

Let me know if anybody has a more impressive collection of Sony BD players.

 

[Phthalocyanine]

33 minutes ago, mindset said:

BDP-6200, BDP-6500, and BDP-6700,

Those would be the Sony BD player models that play SACD from 2014, 2015, and 2016 respectively, correct?

That's some nice investment and research for the cause!

Off the Topic for a moment -- Do any of these have any noticeable improvements as BD or media players from the 2012-2013 models?

[mindset]

2 hours ago, Phthalocyanine said:

Those would be the Sony BD player models that play SACD from 2014, 2015, and 2016 respectively, correct?

That is correct.  

 

2 hours ago, Phthalocyanine said:

That's some nice investment and research for the cause!

Luckily these units cost just a fraction of an Oppo/Pioneer would.

 

2 hours ago, Phthalocyanine said:

Off the Topic for a moment -- Do any of these have any noticeable improvements as BD or media players from the 2012-2013 models?

SONY revamped the GUI from S6500, and S6500 and S6700 have a much faster processor than those from 2012-2013.   I feel that these new models start playing BD a little faster but I am not quite sure as I spent most of the time on their Linux console.

 

[Kal Rubinson]

13 hours ago, srrndhound said:

Are you storing the FLAC or playing? "On the fly" sorta implies playing. If so, why not just use PCM and avoid the computation of lossless encode/decode? Or is it an interface thing?

I am converting the DSF to PCM as I play it so that I can use room correction/EQ.   I keep it in DSF which is the native format so that I can play (or convert) that as I choose now and in the future.  If I did store the PCM, it would probably be in as FLAC.

[meli]

delete please

[JRODRIGUEZ74740]

Thanks for useful help in this topic. I have a question, is ti pssible to rip the sacd with Oppo 103 that have chip 8550?

 

What could be the reason for not getting the oppo recognize if I correctly introduce the IP of the oppo in the ISO2 DSD window?

I do not know if the problem I have is due to the chip or to the no identification of the oppo in the Iso2dsd

Any help?

Javier