Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Newlines in Comment field changed in the Metaflac output (Read 4834 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Newlines in Comment field changed in the Metaflac output

I'm trying to grab the Comment field from a Flac file using Metaflac, and I'm seeing behavior that doesn't seem intended.

Looking at the file with a hex editor, I see "\r\n" between the lines of the Comment field, but if I do a Metaflac list of this file and pipe it to a file, the file has "\r\r\n" between each line. This sequence is doubled whenever the original had two newlines.

I can reproduce this issue using Disc 1, Track 14 of this OCRemix album (you'll need to use the torrent to get the Flac file):
http://dkc2.ocremix.org/music.html

So is this a bug, or is there some reason Metaflac is doing this?

Newlines in Comment field changed in the Metaflac output

Reply #1 –
It looks like metaflac isn't switching stdout to binary mode, so Windows performs end-of-line conversions.
 

Newlines in Comment field changed in the Metaflac output

Reply #2 –
It looks like every instance of unix LF (\n) is being replaced by windows CR-LF (\r\n). That is what a unix-dos conversion does. I did not study metaflac source code if it implements such funcionality, I did not find any parameter to enable/disable that. Also it could be a feature of some text library, used by metaflac. Perhaps some enveronment variable would disable that.

What OS did you use?

Newlines in Comment field changed in the Metaflac output

Reply #3 –
metaflac does its own fwrites to stdout, but makes no attempt to cater for Windows binary mode that I can see.  I dare say 90% of programs written initially for Linux do the same thing.  There are some workarounds in flac for Windows quirks, but apparently not this one.

Newlines in Comment field changed in the Metaflac output

Reply #4 –
E.g. running metaflac in cygwin, with the bonus of decent scripting environment?

Newlines in Comment field changed in the Metaflac output

Reply #5 –
I'm running Windows 7, just using the standard command prompt, not cygwin.

I did my earlier test using the 1.3.0 binary hosted at Rarewares; I see the same results using the 1.2.1 binary available at Sourceforge.

Newlines in Comment field changed in the Metaflac output

Reply #6 –
Quote from: UNHchabo on
I'm running Windows 7, just using the standard command prompt, not cygwin.


Perhaps cygwin would solve your problem.

Newlines in Comment field changed in the Metaflac output

Reply #7 –
Good solution for this is not as simple as opening files in binary mode. If you can use --export-tags-to=<file> and don't have to route tag info over pipes then you could use this slightly modified version. This version opens the target file in binary mode. Note that then all new line characters are in unix format and some Windows text editors, like Notepad, open them incorrectly. Opening stdout in binary mode works ok for console printing but if the output is redirected to a file, then the target file would be in wide character format but without BOM. This is also opens incorrectly in text editors.
I noticed that metaflac doesn't seem to be designed for multiline tag values at all though. It errors out when you try to import multiline tags.

Newlines in Comment field changed in the Metaflac output

Reply #8 –
Quote from: phofman on
Perhaps cygwin would solve your problem.


Nope, I get the same results using Cygwin.

Quote from: Case on
Good solution for this is not as simple as opening files in binary mode. If you can use --export-tags-to=<file> and don't have to route tag info over pipes then you could use this slightly modified version. This version opens the target file in binary mode. Note that then all new line characters are in unix format and some Windows text editors, like Notepad, open them incorrectly. Opening stdout in binary mode works ok for console printing but if the output is redirected to a file, then the target file would be in wide character format but without BOM. This is also opens incorrectly in text editors.
I noticed that metaflac doesn't seem to be designed for multiline tag values at all though. It errors out when you try to import multiline tags.


I'll clarify that I'm actually trying to modify FlacSquisher to grab the comment tag; I was just dumping the tags from the command-line in order to reproduce the issue. This isn't a one-time thing, so I don't want to use a custom binary -- I'd prefer to get a fix into the main release if possible, again assuming this is a bug.

I noticed that OggEnc will grab the tag without modifying it, if that helps.