IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Log embedding problems with new EAC Version 1.0b1
Xenion
post Dec 10 2010, 23:26
Post #1





Group: Members
Posts: 1042
Joined: 23-May 02
From: DE
Member No.: 2107



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

This post has been edited by Xenion: Dec 10 2010, 23:27
Go to the top of the page
+Quote Post
soiaf
post Dec 11 2010, 11:02
Post #2





Group: Members (Donating)
Posts: 74
Joined: 13-May 05
From: Dublin, Ireland
Member No.: 22024



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

CODE
wavpack -m -t -w "CUESHEET=@*.cue" --write-binary-tag "LOG=@*.log"
Go to the top of the page
+Quote Post
Xenion
post Dec 11 2010, 19:14
Post #3





Group: Members
Posts: 1042
Joined: 23-May 02
From: DE
Member No.: 2107



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)
Go to the top of the page
+Quote Post
greynol
post Dec 11 2010, 21:46
Post #4





Group: Super Moderator
Posts: 10347
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Xenion @ Dec 11 2010, 10:14) *
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.

This post has been edited by greynol: Dec 11 2010, 21:47


--------------------
Breath is found in plots and DR figures.
Go to the top of the page
+Quote Post
soulsearchingsun
post Dec 12 2010, 01:30
Post #5





Group: Members
Posts: 145
Joined: 27-January 05
Member No.: 19370



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.
Go to the top of the page
+Quote Post
Kohlrabi
post Dec 12 2010, 18:53
Post #6





Group: Super Moderator
Posts: 1150
Joined: 12-March 05
From: Kiel, Germany
Member No.: 20561



Can't you just pipe the log through iconv before embedding?


--------------------
It's only audiophile if it's inconvenient.
Go to the top of the page
+Quote Post
Xenion
post Dec 13 2010, 16:59
Post #7





Group: Members
Posts: 1042
Joined: 23-May 02
From: DE
Member No.: 2107



QUOTE (greynol @ Dec 11 2010, 21:46) *
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...
Go to the top of the page
+Quote Post
greynol
post Dec 13 2010, 18:58
Post #8





Group: Super Moderator
Posts: 10347
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Agreed and those requests are now being made. wink.gif


--------------------
Breath is found in plots and DR figures.
Go to the top of the page
+Quote Post
bryant
post Dec 16 2010, 15:47
Post #9


WavPack Developer


Group: Developer (Donating)
Posts: 1297
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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! smile.gif
Go to the top of the page
+Quote Post
bryant
post Dec 23 2010, 07:26
Post #10


WavPack Developer


Group: Developer (Donating)
Posts: 1297
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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! smile.gif

download

Thanks!
Go to the top of the page
+Quote Post
Xenion
post Dec 31 2010, 12:54
Post #11





Group: Members
Posts: 1042
Joined: 23-May 02
From: DE
Member No.: 2107



it's working perfectly
Go to the top of the page
+Quote Post
DARcode
post Dec 31 2010, 16:08
Post #12





Group: Members (Donating)
Posts: 682
Joined: 10-January 05
From: Italy
Member No.: 18968



QUOTE (bryant @ Dec 23 2010, 07:26) *
[...]BTW, I have also switched from Visual Studio 2005 to 2008, so expect anything! smile.gif
Could you please advise what we should look out for so that the testing scope is restricted a bit?


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.43 -V 100
Go to the top of the page
+Quote Post
bryant
post Jan 4 2011, 03:36
Post #13


WavPack Developer


Group: Developer (Donating)
Posts: 1297
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (DARcode @ Dec 31 2010, 07:08) *
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! smile.gif
Go to the top of the page
+Quote Post
bryant
post Jan 4 2011, 03:38
Post #14


WavPack Developer


Group: Developer (Donating)
Posts: 1297
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (Xenion @ Dec 31 2010, 03:54) *
it's working perfectly

Thanks for letting me know; this will definitely go into the next release (and thanks again for letting me know).
Go to the top of the page
+Quote Post
Xenion
post Feb 5 2011, 13:59
Post #15





Group: Members
Posts: 1042
Joined: 23-May 02
From: DE
Member No.: 2107



do you already have a release date in mind?
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th December 2014 - 21:32