I'm converting my .ISOs to .CSO format. However, it is very common that I get the LBA error when converting. The way I've found around this is by selecting "Use UMD Standard Padding" rather than "Use no extra padding".
The thing is, I can find no info on what these options really do. Is there any disadvantage to use "standard padding"? To me, the CSOs seems to be of virtually exactly the same size so there seems to be no advantage to use "no padding".
Also, the LBA error seems to be quite common, and is especially enervating when batch converting. If it can't be easily fixed, a graceful failure, logged message, and proceeding to the next in the queue would be preferable.
Even though you say I shouldn't see any errors of this kind, batch processing do fail frequently without error messages, whereupon all processing cease (even though the program still appears to run). When running a manual conversion ("save as") on the files that fail I get the LBA error, which however generally can be circumvented by selecting "use no extra padding". Thus, you might be right in that batch processing doesn't fail with LBA errors (since no error is displayed) but the files it fails on do all give LBA error in normal conversion mode. Seems more than a coincidence.
Batch processing unfortunately seems quite unstable, which I am very sad to say, since it is a wonderful feature.
I'm still converting my .ISO collection to .CSO and have noticed that there's actually quite a few of my .ISOs that have invalid LBA headers. These can generally not be converted to any other format, and will as a rule (with some few exceptions) not load on my PSP.
Is there any way of "rescuing" these ISOs? And could perhaps UMDGen be furnished with an automatic (or selectable) "Invalid LBA rescue" mode/function?