[REQ] Use shared name of files excluding [.ext]

[sevdestruct]

Thank you for making Keka. I use it regularly and promote it heavily amongst our user base for use with ROMs in our GitHub project: Provenance.

I'd like to make a feature request:
When dropping a group of files to compress onto Keka, it defaults to Compressed file.[ext] and adds numbers subsequently, even if the filenames are the same as a pair, such as disc image multi-file sets, which makes batch processing multi-file sets into single archives impossible and thus very time-consuming and difficult to 'Archive as single files' (as it they won't be grouped in sets) and 'Delete file(s) after compression' (as the filenames are lost) so it has to be done manually per set, not batched.

But we could infer the filenames from the shared naming to resolve this:

Examples of basic multi-file sets:

[shared-filename].bin
[shared-filename].cue

[shared-filename].img
[shared-filename].ccd
[shared-filename].sub

[shared-filename].iso
[shared-filename].cue

The basic idea of this would be to infer the archive name from the commonality of the shared filename, excluding the variable .ext —which would allow for queueing of large disc image libraries that have multi-file sets, and using the delete after archiving feature, to archive in large batches, simply dragging and dropping the file sets.

Suggestion: Archive as:

[shared-filename].7z,  .zip,  .etc…

---

As a more advanced version it would be also nice if it could infer a set from common file-naming conventions such as…

Example of complex multi-file sets:

[shared-filename] (Disc 1).bin
[shared-filename] (Disc 1).cue
[shared-filename] (Disc 2).bin
[shared-filename] (Disc 2).cue
[shared-filename] (Disc 3).bin
[shared-filename] (Disc 3).cue
[shared-filename].m3u

—by excluding the variable filenaming as 'tails', when the majority frontend naming is shared and equivalent.

Suggestion: Archive as:

[shared-filename].7z,  .zip,  .etc…

---

Additionally, if any of this could be done in a single drop instead of in queued groups, even better, but I'd be happy with the first phase of this, if there is interest in it.

• Infer name of archive from basic shared filename as multi-file sets
• Infer name of archive from complex shared filename base, frontend or majority as multi-file sets
• Optional setting to parse single drop large batches and segregate/auto-queue for processing multi-file sets as single archives.

[gingerbeardman]

Related #188

[sevdestruct]

@gingerbeardman, Thanks for the upvote on this, but not sure it's very strongly related to the other thread—maybe in terms of inferential naming, but I think the suggestion here is a bit more universal than inferring from containing folders… I think I agree with the commentary on that thread.

[sevdestruct]

As for the 3rd (and maybe 2nd) part of the request…
Thinking something like this… with a dependency on the parent Archive as single files:

disabled	enabled

—also suggest moving Delete files(s) after compression to bottom.

[aonez]

Thanks @sevdestruct for such a complete request. Cool project you're working on, by the way.

So if I got it right, the thing will be:

• If input files are a set (i.e. bin+cue with same name), use shared name as output name
  • Optionally detect multi-disk/parted set and use shared name
• Try to detect multiple sets and compress them separately

I'm thinking in a check in the Preferences for Detect multi-file sets, so this behaviour only applies to people that will benefit from this feature and activates it, and if the "Archive as single files" option is selected, detect multiple sets. Maybe also changing the check literal to Archive as single files/sets if the option in the Preferences is activated.

[sevdestruct]

Thanks! Give it a test run on your iOS/tvOS device(s) sometime and drop by our Discord server.

Yeah, i think that's basically it, although in 2nd part of your list I would try to do it universally versus specifically to disk # or part # …instead opting for something more universal if possible, i suggested above:

—by excluding the variable filenaming as 'tails', when the majority frontend naming is shared and equivalent.

…then again, today I encountered these filenames:

D (USA) (Disk 1) (Track 1).bin
D (USA) (Disk 1) (Track 2).bin
D (USA) (Disk 1) (Track 3).bin
D (USA) (Disk 1).cue
D (USA) (Disk 2) (Track 1).bin
D (USA) (Disk 2) (Track 2).bin
D (USA) (Disk 2).cue
D (USA) (Disk 3) (Track 1).bin
D (USA) (Disk 3) (Track 2).bin
D (USA) (Disk 3) (Track 3).bin
D (USA) (Disk 3).cue
D (USA).m3u

…an extreme case which though it makes me think of scenarios where the command part may not be the majority, but nonetheless prefixed identically. Perhaps when words like Disk, Track, Part and numbers are detected, can be an extra failsafe just incase the prefixxed text is actually the minority but still identical and still a set.

I am sure there are filenaming conventions that have a prefix that are not considered a set but are just similar types of things that start with the same kind of naming: Invoice - 0001.pdf, Invoice - 0004.pdf for instance aren't necessarily a set of files that need to be archived together, which is also why i felt a toggle in the main window was more beneficial to allow grouping or not…

Though, I feel there is definitely a means to make this rather catchall and universal if we get clever. But before it's robust enough automatically, might need easier access to a toggle. (maybe the first version of this just allows grouping of things that start the same (regardless of majority) without getting too clever, yet.

Thoughts?

[aonez]

@sevdestruct take a look at the latest dev build:
https://github.com/aonez/Keka/releases/tag/v1.2.0-dev.3742

You can set a custom name for compression using placeholders. For this issue, you'll want to use %s that prints the shared name. Is not specific for bin+cue but is more customizable.

Let me know what you think.