Hello,
i'm using the following commandline to embed eac log with wavpack:
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
Maybe you need to now treat the log files as if they're binary, can you try
wavpack -m -t -w "CUESHEET=@*.cue" --write-binary-tag "LOG=@*.log"
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)
why are logs now in unicode?
To satisfy continual requests (http://www.google.com/#sclient=psy&hl=en&safe=off&site=&source=hp&q=site:www.digital-inn.de+%2BEAC+%2Bunicode&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=267856ed3ee60de5) by people who I would assume need unicode in order to properly title their albums.
Have you tried --no-utf8-convert?
--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.
Can't you just pipe the log through iconv before embedding?
To satisfy continual requests (http://www.google.com/#sclient=psy&hl=en&safe=off&site=&source=hp&q=site:www.digital-inn.de+%2BEAC+%2Bunicode&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=267856ed3ee60de5) 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...
Agreed and those requests are now being made.
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!
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 (http://www.wavpack.com/wavpack-4.60.2a.zip)
Thanks!
it's working perfectly
[...]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?
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!
it's working perfectly
Thanks for letting me know; this will definitely go into the next release (and thanks again for letting me know).
do you already have a release date in mind?