Thanks I was just wondering it would have been easer for people but not so curious as to test it when I'm already finished with doing it without cue files. But if anyone decides to do it the build in scraper works perfectly for scraping but skyscraper wouldn't for some reason but I had all the cue files from when I made the CHD files so I just scraped them and edited the gamelist. And yet agian thank you mitu for the quick response your amazing

Excellent thank you!

@Clyde said in Linux - script to batch convert PSX bin/cue to CHD: You might want to expand it to extract ecm-compressed files I'll drop just another one-liner here that decompresses all .ecm files in the current directory: for i in *.ecm; do ecm-uncompress "${i}"; done Please note that you might need to install the ecm tools first via the command sudo apt install ecm.

@muldjord Thanks - that works well. I've modified my script output a one-liner to execute Skyscraper as you suggest. It'd be nice if there was a way to pipe a bunch of those "--query "md5=HASH" FILENAME" pairs into the cmd, so it could minimize the startup/rampdown stuff and provide better progress tracking. But, it moves me forward. Thanks a ton!

@sssetz Thanks for the updates! Any luck since? Also, you said in your last post someone confirming they had it working for their RPi. What version? 4 I assuming?

I've been considering compressing roms lately as I keep them uncompressed for all systems to prevent SD write cycles from extractions. These wouldn't extract or cache whatsoever, right? Also does RetroArch cache from my current .bin's and .cue's to "/tmp/Retroarch/"? I've been considering changing RetroArch's tmp to "/tmp/" (a RAM drive) but that would choke a pi3 if it tried to cache a PSX game, thus I'm trying to trim them without the need of extraction.

@mitu Yes I tested them on PC and they aren't working on PC either so definitely seems to be a problem with the files themselves. Here is a pastebin of the info command: https://pastebin.com/s6g48Nr7

How does PSx-rearmed cope with multi-disc files as .chd?

@quicksilver it sure does. I know support for Chd v5 was added to the Libretro core last year, it looks it was added for the standalone emulator also.

You can use iso+ogg for more space (edited with cue files) with games who have many sound track and lr-genesis-plus. Turborip is fine for compress in that format. Chd is fine too and more easy, but more heavy in general. Picodrive use cso+wav but i don't use it.

@mitu I think it's from the limited specs of the Pi Zero. I was actually really surprised that both CD based systems even worked on a Pi Zero in the first place. Somebody told me that they tried CHD files for both emulators on a Pi Zero and the Sega CD didn't perform well. Essentially a CHD File is a modified 7zip archive, so I'm not really surprised. I will eventually test it myself and update this thread when I know.

@gt46l Yes, I did my own research and decided that you have no idea what you're talking about and are spreading false information. The tool PSX2PSP produces PBP files that can be re-extracted into bin/cue files with no loss in audio or video quality. You say you converted 1200 game images with PSX2PSP and all the time you thought the audio tracks were compressed into mp3? You are not the smartest tool in the shed then, because the size difference would be enormous for many games if that were the case. (I don't care what Sony has done with its own PBP releases, they are probably lossy.)

I recommend this thread also, for info about the different MAME versions on RetroPie, which games run best at what core, etc.

Probably the wrong versions of the chds or roms. But anyhow: i dont think that the chd titles will run fast enough to be playable, they need much power which the Raspberry does not offer.

@starmaker69 said in Most Accurate and Best MAME? and few question on game types.: and @BuZz out of curiosity are you the same BuZZ from a site known as Buzzboks? Not me :)

they work in 0.78. see the compatibility list for notes on performance (i.e. that they are unplayably slow on pi 3)

@ebtalk nm it was answered already