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: Log embedding problems with new EAC Version 1.0b1 (Read 13365 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Log embedding problems with new EAC Version 1.0b1

Hello,
i'm using the following commandline to embed eac log with wavpack:
Quote
wavpack -m -t -w "CUESHEET=@*.cue" -w "LOG=@*.log"

EAC logs used to be encoded in ansi. Now with the new version 1.0b1 they are encoded in ucs-2 little endian. (At least that's what notepad++ says)
When you embed the new logs wavpack seems to drop its content. When you unpack it, these log files are just empty

Thanks

Log embedding problems with new EAC Version 1.0b1

Reply #1
Maybe you need to now treat the log files as if they're binary, can you try

Code: [Select]
wavpack -m -t -w "CUESHEET=@*.cue" --write-binary-tag "LOG=@*.log"

 

Log embedding problems with new EAC Version 1.0b1

Reply #2
well this is working (restoring also) but foobar does not display the log file anymore.

i'm not sure if this is a eac problem (why are logs now in unicode?) or wavpack problem (cannot embed unicode logs?) or now a foobar problem (does not display logs embedded as binary data)

Log embedding problems with new EAC Version 1.0b1

Reply #3
why are logs now in unicode?

To satisfy continual requests by people who I would assume need unicode in order to properly title their albums.

Log embedding problems with new EAC Version 1.0b1

Reply #4
Have you tried --no-utf8-convert?

Quote
--no-utf8-convert = don't recode passed tags to UTF-8, assume they are UTF-8 already

The text fields of APEv2 tags are encoded in the UTF-8 varient of Unicode, so when tag information is passed in on the command-line (which is normally multibyte encoded in WavPack's case) they are converted to UTF-8 before being stored. If your system is already passing the strings in UTF-8, use this option to prevent double conversion.


I assume that this wouldn't work because UCS-2 equals UTF-16, but I don't know enough about the internals of APEv2 tags to rule this out completely.

Log embedding problems with new EAC Version 1.0b1

Reply #5
Can't you just pipe the log through iconv before embedding?
It's only audiophile if it's inconvenient.

Log embedding problems with new EAC Version 1.0b1

Reply #6
To satisfy continual requests by people who I would assume need unicode in order to properly title their albums.


OK but I wonder why cuesheets are still in ANSI which is more important for Trackdisplay...


Log embedding problems with new EAC Version 1.0b1

Reply #8
The problem is simply that WavPack only accepts text tags in ANSI (which are converted to UTF-8 because that’s what APEv2 requires) or UTF-8 (which are obviously not converted when the --no-utf8-convert option is used). This is true whether text is passed in on the command line or from a file.

Using binary tags will allow the UCS-2 or UTF-16 tags to be stored and restored, but most programs accessing tags that are supposed to be text (i.e., everything except images) will probably ignore them if they have the “binary” bit set because they only what to deal with UTF-8 (which is what Foobar obviously did).

I have been thinking a little bit about a solution to this, which will become even more critical if EAC cuesheets switch to 16-bit Unicode also as greynol suggests. My first thought was to provide a command-line option like --text-files-are-unicode, but of course that would not work in this case because the cuesheet is still ANSI. In most cases it should be possible to guess the text format correctly, so I’ll try that first.

Thanks for bringing this issue up, and hopefully I’ll have some solution for you to try shortly! 

Log embedding problems with new EAC Version 1.0b1

Reply #9
I have made a quick update to the WavPack command-line program on Windows to support 16-bit Unicode text files. It uses the BOM character to identify them  (which I verified that EAC is putting on the log file).

Any verification or testing is greatly appreciated. BTW, I have also switched from Visual Studio 2005 to 2008, so expect anything! 

download

Thanks!

Log embedding problems with new EAC Version 1.0b1

Reply #10
it's working perfectly

Log embedding problems with new EAC Version 1.0b1

Reply #11
[...]BTW, I have also switched from Visual Studio 2005 to 2008, so expect anything! 
Could you please advise what we should look out for so that the testing scope is restricted a bit?
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Log embedding problems with new EAC Version 1.0b1

Reply #12
Could you please advise what we should look out for so that the testing scope is restricted a bit?
The most obvious problems I would suspect are things like incompatibility with various flavors of Windows or weird dependencies, or problems with pipes or being executed by other applications, stuff like that. At first the performance was much worse than the previous release, but I found a compiler switch that had not been translated from the previous VS project, and so now it seems pretty equivalent. Thanks! 

Log embedding problems with new EAC Version 1.0b1

Reply #13
it's working perfectly

Thanks for letting me know; this will definitely go into the next release (and thanks again for letting me know).

Log embedding problems with new EAC Version 1.0b1

Reply #14
do you already have a release date in mind?