Loading of zipped multi-.bin / .cue files

[SpaceAgeHero]

Please add support for loading multi-bin / .cue files that are compressed in a single archive (e.g. Redump PSX games).

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29531075-loading-of-zipped-multi-bin-cue-files?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github).

[inactive123]

I dont think that could even work.

[SpaceAgeHero]

Why not? Loading of compressed ROMs and ISOs is possible already. However only the selection within the archive is being extracted into a temporary folder (only the cue file for instance, which is pretty much useless). An option to extract all files in an archive would help.

[oxavelar]

I agree, this would work and that would make zip of .bin+.cue files work if packed as a single zip.

Keeping track of the files to be deleted upon exit should be a matter of finding the content of the *.zip with something equivalent or similar to:

unzip -l zipfilename

[andres-asm]

if things were that simple

On Wed, May 4, 2016 at 11:46 PM, Omar Avelar notifications@github.com wrote:

I agree, this would work and that would make zip of .bin+.cue files work if packed as a single zip.

Keeping track of the files to be deleted upon exit should be a matter of finding the content of the *.zip with something equivalent or similar to:

unzip -l zipfilename

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/libretro/RetroArch/issues/2614#issuecomment-217076033

[kivutar]

I think it would be possible to support a cue+bin in a zip. But not many cue+bin in a same single zip.

In fact, RetroArch almost support it already:

We already support a .nes or .sms in a .zip. So having some DATs containing the CRC of .cue would work without code change. And Redump already distribute such DATs.

The only system where this approach would cause problem is PSP, because nobody uses cue in the PSP world. And redump doesn't support PSP officially yet. IIRC.

However, it would be beneficial to PCE CD, Sega CD, and Dreamcast. We would have scanning for these systems implemented without effort.

Compressed ISO loading is already supported?

EDIT: I'm trying it, and loading the game takes ages because of the extraction. So are you sure this feature request is worth it?

[oxavelar]

Well, I ended up wrapping this on my launch script anyway. Since not all of them probably needed this due to performance issues (for now it is perfectly fine since I load the ROM's from an NFS share, and extract them in /tmp locally when the Intel NUC starts execution the Emulation).

Here's what I ended up doing in case anyone's interested.

unzip -vl "$ROM_FILENAME_PATH" | grep -q cue                                        
if [ "$?" -eq 0 ]; then                                             
  unzip -qo "$2" -d /tmp/                                           
fi

[RobLoach]

Redump already distribute such DATs.

I'd be willing to push the PRs up for the Redump DATs. They provide both the DAT and a seperate DAT for the BIOS.... Would there be any license issues with us distributing them?

[SpaceAgeHero]

I don't mind if extraction takes a while. Well, I guess a progress bar would be nice.

:-)

[ghost]

Multiple BIN in a single 7z/zip is already supported, the only thing that's not currently supported is extracting the bin file and using that as the content if you choose a cue file inside the archive instead... but the bin files can be loaded directly without a cue.

[RobLoach]

extracting the bin file and using that as the content if you choose a cue file inside the archive instead

Is that because the serial method takes precedence? There's a PR to remove that, may want to re-investigate it.

[SpaceAgeHero]

Many PSX titles are multi-track games. If only one (assumingly the main) bin file is loaded, then obviously music won't play in the game. So it's the cue file that should always be loaded.

Please reconsider this request. Basically an additional RetroArch-configuration would be good allowing to extract all items from an archive to a temporary folder (or even only memory).

[andres-asm]

Please go to the forums for help. This is a development issue tracker.

Thanks.

On Mon, Oct 3, 2016, 3:34 AM Fadi5555 notifications@github.com wrote:

On me it didn't show PBP file I don't why? Any help please?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/2614#issuecomment-251053202, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0JfKHyAsz6EUc8HY068CVkkGXUuCks5qwL34gaJpZM4G9ieH .

[andres-asm]

https://github.com/libretro/RetroArch/issues/4331

[rz5]

Had another user complain about beetle-psx not being able to run zipped bin/cue files. The frontend knows which core is gonna play the content, yes? So right before deciding what to extract, we check a list of naughty cores (DOSBox, beetle-psx, cores that accept media that would otherwise be some type of CD media) and if the core is in the naughty list, we extract everything.

[hizzlekizzle]

@rz5 I believe we've committed to not hardcoding frontend "magic" functionality for any cores as part of the reference frontend thing.

[rz5]

Then a less hacky way to go about it, as @Vaporeon suggested: it is known that cue sheets aren't the content itself since they refer to other files, so they can be considered metadata.

RetroArch could behave differently for these types of files (.cue, .ccd, .m3u, etc.) if they're in archives.

[Aerocatia]

While that would work @rz5 it gets to the point of do we even want it to. Archiving disc based games like that is rather inefficient and the content needs to be extracted before runtime. Formats like CHD are better at the compression for instance because it uses lzma for the data section and flac for the CD audio. The entire stream also does not need to be decompressed before the content is run.

I guess a feature like this will be useful for disc based cores that do not support a dedicated compression format but it should be a fallback at most.

[ofry]

But if I want to create playlists via RetroArch, I need certain sets. And all of these sets (Redump, Trurip, TOSEC, etc.) goes in that state (each disc, cartridge, etc. in separate ZIP).

[gingerbeardman]

I'd also like to see this, though my use case is different.

On px68k I'd like to use .m3u to mount multiple disks at once.

Aquales.m3u:

Aquales_2_GAME.dim Aquales_3_SAVE.dim Aquales_1_INTRO.dim

This works. Disks 2+3 are mounted as FDD0+FDD1 and Disk 1 remains to be swapped to if required.

But I'd like to compress all four files. Right now only the first file in the zip remains in a temp directory after I choose the archive. I can control the order of files in the ZIP and it's always the first file.

@rz5 suggested that if an .m3u file is found in an archive retroarch should be have differently. I would suggest that it extracted all files and kept them around until the content is closed.

As far as I know .m3u is supported by MSX, PS1, X68 and maybe others.

[SpaceAgeHero]

VFS is implemented, right? So how could this be helpful? Do cores need to be updated in order to be able to achieve this?

[barbudreadmon]

FYI, zipped cue+bin is supported at core level in the yabause-based cores.

[JukePlz]

This also needs to be supported by file scanning. Right now some cores support loading of zipped cue+bin files but Retroarch content scanner doesn't recognize the content for playlist usage.

Edit: I mean the default folder scanning behaviour, it's possible to use the manual scan feature to add them.

[RobLoach]

Possible solution around this could be over at https://github.com/libretro/RetroArch/issues/4331

[barbudreadmon]

Between using extra disk by extracting the zip, and using extra ram by mapping the disk into memory (the way arcade and yabause-based cores work), i certainly prefer the second method, however idk if it could be implemented frontend-side.

[Quest79]

So just curious why zip is such an issue but pbp works fine? Is there something about zip that makes this a pain?