You have detected a well known design quirk of the Mp3tag export scripting language.
Because Mp3tag 'uses even the paper on which the script is written as significant code content', will say, this is not a format free scripting language.
It is not possible to write a zero byte file.
If you want to prevent unwanted blank lines you have to code the script into a single stream line and force needed linebreaks by dedicated $char(13)$char(10) sequence.
But I expect it will not work absolutely satisfying, because even this one line is delimited by the EOL character sequence CRLF in the script file, what is the 'paper'.
And because even this 'paper related' EOL is significant in a Mp3tag export script, there will be created an empty line in the output file.
In my opinion this is a worse design quirk.
Oh, well, did you notice, that I wrote $loop()$if() in a single line? ;-))
This seems to work well! Is there a not-so-experienced-user friendly table somewhere listing all theses char-values and their meanings? From what I found, I would not guessed, that (Unicode hex values?) 13 and 10 produce a line break.
Here's my working example, exporting ReplayGain's according to year (so far without any valid trend ;-))
$filename(ReplayGainStats.dat,utf-8)# ReplayGain values and year of %_workingdir% at %_date%
# YEAR, REPLAYGAIN_ALBUM_GAIN, REPLAYGAIN_ALBUM_PEAK, REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK
# -, dB, -, dB
That could be avoided with a comment symbol. In TeX and LaTeX % works as comment and one can avoid unwanted linebreaks by putting % at a line's end:
$loopend()This way one ccould write readable sources and produce desired output.
Did you realize the one additional blank line at end oif the output file?
The Mp3tag help manual contains a small description for the function $char(), which states, that it can create any Unicode character. Well ... I hope so ... did not checked it ... $char(0) would be of interest.
Since historical times (I was a child of about ten years old and did not know anything about computers) there are a few special characters, which have the meaning of control characters to manipulate a printer's behaviour, for example 'Carriage Return' (13) or 'Line Feed' (10) and even 'Form Feed' (12) or the 'Bell' (7) or the 'Horizontal Tabulator' (9) or the 'Space' (32) and others.
The first 32 characters in the ASCII character table are reserved for control characters.
See section ASCII control characters in http://en.wikipedia.org/wiki/ASCII
Interesting ... just a few days ago I discovered that the encoder LAME 3.98.4 has made a step forward to work more precisely than its ancestors regarding its own calculation of the replay gain value.
I have recoded some of my music files with my LAMEO optimizer to get a precision now of up to -0.1dB from the maximum scale limit 1.0, which means 0dB.
What can your report tell me? ReplayGain of a song in relation to year?
Back to the problem ... how to avoid unwanted line feeds in Mp3tag report files?
It is too hard for the normal standard user to code all functions and text and so on into one endless stream line. This is far away from practical usage.
Other scripting languages have dedicated constants for characters, which indicate the End Of Line, even for the usage in different systems like @CR (Apple) or @LF (UNIX) or @CRLF (MSDOS/Windows).
Beside there are already some reserved dedicated characters in Mp3tag scripting language: Round and Square Brackets, the Comma, the Single Apostrophe, the Dollar symbol, the Percent symbol, you have proposed to use one special reserved character (maybe a '#' or a '!' or a '=' or whatever) to direct the script parser, where to suppress a 'paper related' LineFeed to not put it into the output text resp. where to take a 'paper related' LineFeed as significant and let it go into the output text.
This could be a (crippled) way to go for Mp3tag without too much changes in the existing parser.
So one have to code the linefeed suppressor at the end of almost all lines in a mte script (... depends on the script).
I didn't search for ASCII as unicode is required. The table at wikipedia is very helpful! The first "letter" I was searching for, long time ago, was the space, $char(32). I can't remember for what purpose ...
I guess you're familiar with the so called loudness war. I had the wild guess, that ReplayGain should correlate somehow with the date of production. I'm afraid I have not enough music files to prove that (I don't see a definite trend in my data. Let me know and I will upload the figures here). BTW, foobar just implemented libebur128 for scanning replay gains.
For the moment for my personal use, I can put code, where no linebreak is allowed, in a single line of *.mte.
On the other hand, a comment-character making code after it "invisible" for the parser, would be very handy. Than I'll probably understand my mte-scripts written years ago.
Do not use a web site, which wants to download something to be run on your PC to identify something on your PC.
I would recommend to use the one and only original resources at http://www.unicode.org/ucd/
The Unicode 'table' starts with all the single-byte characters from the origin ASCII table, then including the rest of the ANSI table, then following many other multi-byte characters given the full Unicode world.