Take in mind that *.cue can contains REM lines (comment lines, like in *.bat), on which most of CUE parsers crashing. Worth to add in IMO in next version.
(thanks so much for posting the link)
I tested my program with a few REMs, not enough to be considered true testing. It will throw an erroneous warning but it will continue (as of v1.0.0 that might be different) - I'll be sure to add it to the support list in the parser section. My parser is designed to handle all the GNU recognised CUE file MODEs, although PSX and Sony only used MODE2 and AUDIO, I support all the official modes.
(no shade being thrown) most people who hobby make software like this work on assumption that the input will always be more or less the same. I purposely researched other software to see what errors could crop op in general to avoid most of them - same story with more than 2 INDEX per TRACK, I have never seen a CUE with more than 2 INDEX for the PSX but I included support up to 99 for the sake of meeting spec. It can take the output of itself and still handle it correctly, since it is still a valid CUE file.
That being said I do plan on adding REM support with direct output at the right place.
What do You mean by "multiple .bin files"? A disc image with separate tracks? Like ReDump way?
I don't know what "ReDump" is, but as you probably correctly assumes it's one CUE file many BIN files. I don't know of a better way to describe it. i made this project just cause i wanted to get some PSX games working with POPS and all the main software was painful to use - I'm not super well versed in what the PSX scene call stuf like multibin files.
Single *.bin or split, doesn't matter. All data will be written in exactly the same way. Until You decide to use TAO which You never should do with PSX games case (must be RAW-DAO).
In theory I agree but there's something f***y about multiple bin files while live burning to a CD in my experience. Some small weird error happens than it can't figure out how to handle that as it goes for the next CUE TRACK. Could just be in my head, granted, but I would say try it out if you can spare the time and CDs lol, It's weird how single .CUE .BIN pairs are just more reliable to me.
Can you make side-by-side video comparison of your app vs. CDMage? I'm sure they're about equal on high-memory PC
Yeah I intend to, wanted to see some interst first which I guess I have gotten lol. Currently working on a overarching library called CLIah (for CLI managment. also on github) for multiple projects including this one. I want to make a full video about explaining everything, but I don't see psx-comBINe as finished enough yet. Soon though, especially if I have motivation like this lol.
For your sake though, I tested my software cs binmerge vs isobuster vs cdmage.
CDMage on windows and WINE (linux) is very slow, mostly because it's either C++ or probably C# and it uses Windows specific IOP methods, so it's quite slow, last touched in 2002 so very oldschool, not bad but a touch slow on both systems. Totally fair considering the size and scope of it vs my project (CDMage average 20sec, mine was 12 sec. All these basic speed tests done with Rayman cause 52 tracks is painful for the software)
binmerge is written in python, it works fine but is just classic python unoptimised, not that you can optimise python as much as other languages anyway, but it makes some weird assumptions that cost it stability and python is just slow. 18secs on my tests
My own code on Windows is a bit slower than on Linux. Partly due to unfinished porting work, and because Windows IO Handler is very weird and slow in its own right. Linux has a near full speed access at any given time, with any given data size and has little latency getting the file ready.
