HiRezGuy

Sorry for font on above. I see the replies as I travel and take notes on my iPhone.

There have been some problems in the thread over the last 2 or so months, so I’m just getting around to providing colour that I wrote but never posted. user was ripping Beethoven and two tracks ended up with the same exact name. —— this is strange. Even with the infamous dacapo_kronos_holmgreen no metadata disc, sacd_extract still used track numbers. I’d check the path length first. I’d also check the target file name length - sacd_extract may chop it to conform to windows limitations thereby creating the same exact name. I got Shostakovich_no8_altus and it also doesn’t have metadata. No issue with track numbers being output, for example, in dsf extract mode. User had a problem with rips over WiFi - very slow, thrashing almost. I can reproduce this. Verizon sucks and throughput is dependent on traffic (duh). Basically what happens is as the signal strength decreases, throughput decreases, and sacd_extract can seem to thrash. It’s not - the WiFi is the bottleneck. Now, this does present another issue however. Say you are ripping over WiFi, the signal begins to weaken, throughput comes down etc. If you run from the command line and redirect output, the frequency of the sacd_extract status messages can create logs that are bigger than the sacd image itself. What happens is the status continues to get output, maybe 1/sec, but the WiFi is so slow that the log build up to very large size. For this case WiFi throughput is down in the 0.n range - extremely low. A dying signal essentially. Numbered folders. Saw that ted_b mentioned this after my most recent post 4-8 weeks ago. On win10 systems with the latest updates, sacd_extract should NOT use numbered folders. This was probably an sacd_extract bug whereby the program didn’t check for a folder before creating it. And the windows api that allows the file system access / manipulation probably had a bug too in that it was allowed to happen. Either way, if you keep your win10 system current, sacd_extract should not use numbered folders any more. Do it as I’ve documented in the sticky notes on p1 — Create a working folder and go from there. (I discovered the problem at the time of my last post as I extracted both 2ch and Mch in the same sacd_extract command invocation - the same folder was used and the 2ch file were overwritten by the mch files.)

Yes you should get the same file every time. If not, the disc is bad obviously. Try cleaning it; maybe even use pledge. Rips between ps3 and sacd_extract checkout fine — checksums are same.

@AudioInventory AuI Converter Producer is nice software. It can convert iso or 64fs dsf to wav64/768 or 32/384 flac, as examples. JriverMC and foobar2000 use a map to get sample rates over 192. foobar2k requires the sacd add-in and the dsf/dff add-in. dbPowerAmp does dsf to 352.8 with an add-in. (Sorry about the font on the last post - iPhone notes update & very short computeraudiophile.com edit time.)

@mook - Do you see those iso creation times for all sacds? Hopefully not bc it would likely mean a bad laser or something. - It could be a problem sacd too - I’m sure you’ve had a cd take a while to rip with eac or something. - other network activity? Clear the counter and make sure it’s just sacd traffic coming in - the counter should match the file system. - other process activity - like win update, something thrashing the hd? I’d start with that kind of stuff. My dsf extraction times are on a pair of ASUS labtops upgraded from Win8 to 10 - I use them for cd and sacd ripping - that’s why I batch it all. For about 60-70mins of audio I get about 11min extract time for 2ch, and 40-50min for 5ch, abt 15-20% longer for 6ch. So, an shm-sacd 2ch DGG-Sibelius-Karajan-Finalndia ~ 40min 1.3gb iso is much less time to rip than 5gb iso single-layer mch DGG-Bernstein-WSS-Kanawa. Anyway - 2 hours is thrashing Mook. I’ll pull my logs and make a report w my specs that shows times that I see when I can.

@mook @t123 Rip an iso. Then use that to play through JRiver or foobar or some other media player. Or use the iso to rip dsf files. Then use your oppo or pioneer or denon to play those. Don’t go over ether or WiFi to go from sacd to dsf. Anyway - do it in two steps and there will be some slight savings (e.g., bis-Beethoven-no9-vanska 5ch ~ 55min for dsf extraction local hd; mfsl-Gershwin-slatkin-6ch ~ 70min for dsf extraction local hd).

Glad that worked out for you. The WiFi bandwidth isn’t the limiting factor; it’s the decoding the sacd_extract.exe performs. Even if you had your sacd image local, it’ll take a bit to get through.

@ted_b: Thanks for making the Pioneer process list a sticky. If it is easier for you to maintain that doc in the context of this thread, say as much in a post, and I'll delete the dbox link. There may be a spelling error or two in the text file at the dbox link, btw. ---------------------------------------- Here are a couple of caveats that I have run into with "sacd_extract.exe". Nothing major at all - nothing that affects operation or processing of SACDs and DSF/DFF files. 1. I mentioned the "Dacapo-Kronos-Holmgreen" SACD in the Pioneer process list; it was an SACD that did not have any metadata for "sacd_extract.exe" to use. See the attached dsf extraction log at the dbox link for the same SACD. Notice the lack of newlines in the status messages. The program is probably outputing a null instead of a newline for those SACDs that do not have metadata included. This is the only SACD I have that does not have metadata, so I cannot confirm the behaviour otherwise. What I can say is this: all other SACDs that I have processed with "sacd_extract.exe" have output status messages terminated by a newline. Definitely not a biggie. 2. Some SACDs are multiple SACD sets. Consider a 2 SACD-hybrid set that contains both stereo and mch audio, but uses defaults for "Sequence Number" and "Set Size" via the SACD metadata. If I run "sacd_extract.exe" in dsf extraction mode, I should end up with four folders, assuming you run stereo extraction first, then mch extraction, for each SACD consecutively: 1. sacd1 stereo; 2. sacd1 mch; 3. sacd2 stereo; 4. sacd2 mch. The first created folder will be named based on the SACD title from its metadata, and subsequent folders have the same basename with a numbered suffix. (This is similar to what is described in the Pioneer process list.) I have a 2-SACD set, "DG-Boulez-BPO-Ravel-Bolero". This SACD causes "sacd_extract.exe" to put all stereo and mch files for both SACDs in the same folder; "sacd_extract.exe" does not create the four folders as I described above - it uses only one folder thereby overwriting previously generated files. This is the only SACD I have where the SACD metadata contains valid values for "Sequence Number" and "Set Size". It's a pretty good feature - "sacd_extract.exe" sees that a set is multi-disc, and then leaves the files in the same folder. The problem is twofold: 1. As I mentioned above, subsequent dsf extractions overwrite previously generated dsf files (since "sacd_extract.exe" is using the same folder to write output); 2. No "Sequence Number" is prefixed to generated dsf files, so you end up with 2 track 1s, 2 track 2s, etc., for a 2-SACD set. Definitely not a biggie. The work-around is to: run "sacd_extract.exe" against the SACD1 iso image for stereo tracks; rename the output folder; run "sacd_extract.exe" against the SACD1 iso image for mch tracks; rename the output folder; repeat the same steps for SACD2; and finally, merge the folders so that there is one stereo folder and one mch folder, each with SACD1 and SACD2 files. ---------------------------------------- I put the logs at the following dbox link for: 1. the "Dacapo-Kronos-Holmgreen" SACD; 2. another 2-SACD set I have ("CCS-BFO-Fischer-MAHLER-2") that uses default values for "Sequence Number" and "Set Size"; and 3. the logs for the "DG-Boulez-BPO-Ravel-Bolero" 2-SACD set. https://www.dropbox.com/s/ph2v415w8c06zad/sacd_extract.exe---logs.rar?dl=1

One of the guis uses java. Both guis are an interface to sacd_extract.exe -- they system call to sacd_extarct.exe. Sacd_extract.exe will be on your system either way you do it. The instructions I provided are a collection of the information in this thread pertinent to the pioneer elite BDp-80d. Nothing more. I offered advice on processing many sacd isos at once using a batch script. Neither GUI can do that either. I did not offer my scripts bc it's more advanced than most users in this thread can handle. (Ps: is this why all the evasiveness regarding my perl mp3::tag question? )

Nice. Sorry for the sloppiness. I meant perl mp3::tag, which is what your code looked like. (I did a project about 10 years ago with mp3::tag. Seeing your code snippet got me thinking about recycling some old code to tag wavs on the fly within this whole sacd-iso-dsf-others process.)

Step-by-step instructions for the Pioneer BDP-80FD. https://www.dropbox.com/s/13mq5pihw0enoqy/SACD Image Creation Process for Pioneer BDP-80FD.txt?dl=0

Can perl mp3tag be used with wav files?

The proper Autoscript folder files for the bdp-80fd is in an archive called "SACD-extract-BDP160.zip" -- use that one and you'll be good.

If you haven't already: Under the bdp80-fd setup screen ensure auto play and auto resume are disabled. Also, disable dynamic ip addresses. If you see the bdp-80fd in network, then the unit is on the net and the pc sees it -- ping unit to ensure. Make sure you are using autoscript for bdp-80fd. Disconnect all USB devices from bdp-80fd other than autoscript drive. Check your firewall settings to make sure the bdp is allowed to be accessed.

Thanks for your insights.