Here's one thing I discovered about GSAR yesterday (I was too annoyed to post it until now). It's a undocumented (shame on you authors) limitation of GSAR.
The next code is almost the same as in "amending cuesheet...":
SET EscapedSourcedir=@sourcedir@
SET EscapedSourcedir=%EscapedSourcedir::=::%
ECHO "@Tools@\gsar.exe" "-sFilename %EscapedSourcedir%\@basename@.wav" "-r%TrackName%.flac" -o "@LogName@.log">>update-log.bat
I'm trying to amend the EAC log a bit to my liking. The following shows what the command expanded and run tells us:
"C:\PROGRA~1\REACT2\tools\gsar.exe" "-sFilename D::\Music\RIPPED\EAC\Various - AnotherLateNight - Tommy Guerrero - 01 - Can't Get Up If You Can't Get Down (US Navy Port Authority Soul Band).wav" "-rVarious - AnotherLateNight - Tommy Guerrero - 01 - Can't Get Up If You Can't Get Down [US Navy Port Authority Soul Band].flac" -o "Various - AnotherLateNight - Tommy Guerrero.log"
gsar: command error, length of search or replace buffer must not exceed 128 chars
I know I could do this same with splitting the GSAR command a bit BUT it's still a could-be-a-problem to long filenames in "amending cuesheet...". Any thoughts on this?
This finding puts the GSAR author's comment about the removed @ functionality into a new light; the comment was: "The @ is not really needed anymore on Win32 due to the length of the command line.".
EDIT: forgot the GSAR error message.