Jump to content
IGNORED

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


ted_b

Recommended Posts

8 hours ago, servoyguru said:

Thanks for the reply.

I did try compiling it on my Mac, but when it got to the 'cmake .' command, it failed with this error


dyld: Library not loaded: /opt/local/lib/libnettle.4.dylib
  Referenced from: /opt/local/lib/libarchive.13.dylib
  Reason: image not found
Abort trap: 6

so can't seem to make my own binary ?

Is there a problem with someone posting a Mac binary if they have managed it?

Thanks

Bother to do some google search?  This is what I found:

https://apple.stackexchange.com/questions/236218/wget-gives-error-dyld-library-not-loaded-opt-local-lib-libnettle-4-dylib

Link to comment
13 minutes ago, servoyguru said:

My apologies @mindset, I should have done that (I normally do for my other coding related problems, but didn't think to do so this time...)

I did some of those things & now seem to have managed to compile it!

No worries.  Glad to hear that it's working now.

 

15 minutes ago, servoyguru said:

before doing the 'cmake .', but when I check version using the GUI, I get


sacd_extract version 0.3.9@setmind-1-gf7419fdf1639cf6a88e95ca7ed45d00a99a78a2a

 

The latest on github is:  sacd_extract version 0.3.9@setmind-8-gae5301f0419644a946479cb9b59bdd5c6cfcf71e

Try 

git pull

or remove the entire source tree and do git clone again.  You can also try removing CMakeCache.txt

Link to comment
20 hours ago, haggis999 said:

 

Your earlier post advising me that a problem had recently been fixed by an update to sacd_extract.exe was attached to a quote from one of my posts. That quote referred to the stereo and multi-channel rips being read in sequence rather than in parallel, so I just assumed that was the problem in question.

 

Did you really mean to quote a different part of my post that referred to erratic starting of the ripping process? If not, then what issue was addressed by the update (I tried checking your Github link but couldn't find anything relevant)?

Sorry, I quoted a wrong message for that.  I meant to say was that the bug that the program quits without doing anything when stereo and multi are both selected for extraction had been fixed.  What I implemented is sequential processing of stereo and multi in one command execution.

 

 

Link to comment
6 hours ago, BluRay444 said:

During the compile I had quite a few errors (attached file is an rich text file in Mac TextEdit format). Despite the errors, the resulting Unix executable appears to be working, although I haven't done an extraction, just run the -v and -? options which resulted in no error messages

I only see one error at the beginning of the log file, and that seems irrelevant.  If your executable was generated and it runs, I believe it was most likely successfully generated.

 

6 hours ago, BluRay444 said:

Can you tell me if java is for the exclusive use of the SACD EXTRACT GUI only? 

Yes.  Java is only for the GUI.  The sacd_extract program has absolutely nothing to do with Java.

 

6 hours ago, BluRay444 said:

The other question I have is about the Github downloads for the GUI- the original release had 13 files and the second version only had 3 files- the license, a readme and SACDExtractGUI.jar... I'

You probably downloaded a source package via "Source code
(zip)" instead of the binary package "SACDExtractGUI.zip".  SACDExtractGUI.zip has always had just 3 files and has never included those 13 files you are referring to.

 

Link to comment
On 10/10/2018 at 7:06 AM, BluRay444 said:

With regard to Java, what I was referring to was not whether Java was also used by the sacd_extract program, but rather if it was globally available to all programs.

I am puzzled by your question.  My best guess here is that you are referring to JRE (Java Runtime Engine)  which is commonly used to run Java-based programs like SACDExtractGUI.  JRE is not included in SACDExtractGUI. What's inside SACDExtractGUI package is just a compiled program in Java.  If you managed to run SACDExtractGUI, that means JRE had been installed by your choice or your operating system's choice . macOS installs JRE (which is widely available in the system once installed) with user's permission when the user tries to run a Java-based program like SACDExtractGUI.

 

On 10/10/2018 at 7:06 AM, BluRay444 said:

I should have said errors and warnings... there were 35 warnings (see attached file). Many are repeated several times.

What is your problem with those warnings?   There are many C programs with lots of compiler warnings in this world.

 

Link to comment
13 hours ago, servoyguru said:

Thank you for SACDExtractGUI, but (for me at least) it doesn't seem to remember the path for the 'sacd_extract' nor the IP address of Server (& even though it displays sacd_extract in 'Program', it doesn't seem to look in same folder for it (as the Sonore version does))

Can these be addressed/fixed please?

No, because that had been implemented from the very first release of the program :)  My guess is that SACDExtractGUI is running in a read-only directory or something like an antivirus program is preventing it from writing to the directory.  It writes its state to SACDExtractGUI.properties when it is closed, and reads it when it starts.  Please check if SACDExtractGUI.properties is generated after the program is properly closed (by clicking on the "X" button at the top of the window).

Link to comment
  • 2 weeks later...
2 hours ago, BluRay444 said:

I'm only reporting results, and not making a judgement; I agree with you, this could be a false positive, but this is the problem with Java, there have been so many security issues with it for so long that people tend to err on the side of safety when there's a question. 

The file the virus scan flagged is sacd_extract.exe which has nothing to do with Java.  So Java is not the problem regarding the virus scan result.

Link to comment
8 hours ago, Phthalocyanine said:

The best way to get a sense of what is going on with this player is connect with telnet.

 

I second this.  I suggest running the following command to check the Linux kernel version on the player if it's accessible via telnet:

uname -r

The sacd_extract program on the player side is only compatible with this kernel version:

Linux sony-player 2.6.35 #1 PREEMPT Sun Nov 30 15:59:53 CST 2014 armv6l GNU/Linux

 

Link to comment
  • 2 weeks later...
2 hours ago, MikeyFresh said:

The first rip was a little bit slow, but the RPi3 b+ in use is connected via WiFi and it's in a metal casing, so that eats up some signal and affects the speed. It's also a short play time SACD, an older stereo recording originally produced for vinyl LP, no surround tracks, so not close to the outer edge of the disc where the read speeds are greater:

 

1362277198_PiExtract.thumb.jpg.6dc5c9a15264a35480cb18f67b00add1.jpg

I believe that disc is not DST-compressed in which case little CPU resource is needed for ripping.  You will probably see much slower speed with normal DST-compressed discs.

Link to comment
1 hour ago, MikeyFresh said:

 

Are the bulk of the stereo only discs not DST compressed?

 

I think I remember that only the surround tracks are typically DST compressed?

I have a few stereo only discs, and they are not compressed.  Surround tracks are normally compressed (not sure if it's mandatory though).  One thing you can try is to convert a local ISO of the ripped disc to DSF on a PC .  If you see tens of MB/s, that disc is probably not compressed.

Link to comment
On 11/8/2018 at 12:33 PM, Nexus3 said:

@mindset

 

Since your tools have gone, where hardly any other disc ripper has gone before - the ARM world around a dwarf sun, the Android cluster shouldn't be that far away.

Should you ever choose to port sacd_extract(+GUI) to APK, do consider us for beta testing ?

 

Sounds like a fun project, but I'm not sure how useful that will be.

Link to comment
6 hours ago, wedgeworld said:

Some updates to my being unable to have success. 
We now have a linksys Velop wireless system. My signal is way better.
I have only had the Oppo door open automatically once. Other times I had to turn it on, with the thumb drive already inserted, and then the door did a very quick open close thing, with or without a disc in.
Finally when I clicked EXECUTE in the Sonore software I didn't get an error. However, I didn't get anything showing in the Sonore software screen and it doesn't appear that the USB stick is doing anything.

one thing to note, on the Oppo main screen the icon that just says network, if I select that option is shows 0/0. If I select it it spins for a while but nothing shows up. But I am on my network as we were able to use the netflix app.

 

I've never been much for networking my computers. Is it possible some sharing or other networking item is not set correctly on my Mac?

I would suggest confirming that IP address belongs to the OPPO not something else in your LAN (you should be able to do this in OPPO's menu) and then try pinging the IP address.  If the IP address belongs to the player and there is echo,  then the server program is probably not running properly on the player side.

Link to comment
17 minutes ago, wedgeworld said:

I now have put the autoscript folder on a new smaller fat32 stick that is only 4gb. I also discovered I had a stick in the rear port as well, which I removed. 

Yes, this is a problem.  Try power cycling the player with no USB memory and then insert the one with Autoscript.

Link to comment
  • 2 months later...
9 hours ago, MikeyFresh said:

The S790 was tested and found to be non-compatible, which is odd in that it does have the correct MediaTek CPU, but unless something changed that I failed to follow, all attempts to get that machine working by a couple of different testers failed for unknown reasons.


I do not own a S790, but tried looking into its latest firmware.  Something suggests that its kernel probably has ARMv7 signature while all the working units are ARMv6l to my knowledge.

 

The sacd_extract program on the player side loads a kernel module embedded in the program when it is invoked.  The kernel module is intended for ARMv6l, and if the running kernel doesn't match, the module will not be loaded and obviously the sacd_extract program terminates.

 

Whoever has a S790 can try telneting to it and do this to check the vermagic:

 

uname -r

 

On working units like S390, I see this:

Linux sony-player 2.6.35 #1 PREEMPT Sun Nov 30 15:59:53 CST 2014 armv6l GNU/Linux

 

Link to comment
2 hours ago, Phthalocyanine said:

 

Concerning the source code that @Kal Rubinson has linked to.

 

I had a pm discussion with @skepitcal a while back about that, and would be interested in the thoughts of some of the rest of our code-savvy members on this issue.

 

Two things are missing from the repository of the original sacd_extract that @Kal Rubinson linked to:  development essentials for MT85xx SoC (which must come from the SoC vendor and can be proprietary) and glue code between sacd_extract and MT85xx libraries/modules.  These are are actually where the magic is happening, and we do not have much luck without them for recompilation of sacd_extract_160.

 

Link to comment
51 minutes ago, Phthalocyanine said:

@mindset is there any way to tell whether the sacd_extract for Oppo is compiled for Arm 6 or Arm 7?

Or alternately, whether the Oppo 103 & 105 mediatek architecture is Arm 6 or Arm 7?

You can just open the sace_extract binary with a text editor and search for "vermagic".  sacd_extract_160 has this:

vermagic=2.6.35 preempt mod_unload ARMv6

This belongs to the kernel module file embedded in the sacd_extract_160 program.

 

I am not sure what kind of ARM version Oppo uses since I do not own one.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...