nyaochi wrote:
> Hi Carsten,
>
> I was planning to migrate from libid3tag to TagLib as libid3tag seems to
> have some problems with tags generated by MusicBrainzPiccard. But I
> found serious problem of using TagLib for those who use non ISO-8859-1
> characters (such as Japanese, Chinese, etc.) daily. In Japan, we store
> Japanese tag-values to ID3v1 and non-unicode ID3v2 in Shift_JIS (CP932)
> encoding for the historical reason. TagLib couldn't handle these tags
> properly since it preserves the specification (we must interpret
> non-UNICODE tag with ISO-8859-1 charset) so strictly. I can't change the
> behavior of TagLib to assume non-UNICODE values to be written in
Shift_JIS.
>
> So I removed the code to use TagLib and took back the old code to use
> libid3tag. This is the latest source code which will be released as the
> next version:
> http://nyaochi.sakura.ne.jp/temp/easyh10-1.5.tar.gz
>
> Could you test this source tar-ball? I think the degression is caused
> only by the migration. The source code also includes the bug-fix found
> today.
This is the one for Geoff's bug?

Benjamin
>
> Cheers,
> Nyaochi
>
> Carsten Pfeiffer wrote:
>> On Saturday 07 October 2006 22:41, you wrote:
>>
>>
>>>> I want to make sure that Carsten's problem will be solved with the
>>>> latest CVS code. It would be great if you could check the latest
package.
>>> I sent him the link, but I see no reason why it wouldn't, since he's the
>>> one who wrote the patch, and it is included in the CVS release.
>>
>> Yes, the patch I wrote definitely fixes the problem for me.
>> I just tested the tarball from dlgeek.net (I'm on i386 so cannot test
>> the .deb). It works fine, although it seems to be a little bit more
prone to
>> filename encoding problems:
>>
>> #0 ucs2len (string=0x0) at ucs2char.c:71
>> #1 0x080591a5 in ucs2dup (src=0x0) at ucs2char.c:190
>> #2 0x08053e53 in h10db_set_title (h10db=0x8064310, index=56,
value=0x0) at
>> h10db.c:856
>> #3 0x0805a98c in gettag_set_info (h10db=0x8064310, index=56,
info=0xb45e4e08)
>> at getmediainfo.c:136
>> #4 0x0804df70 in easyh10_database (path_to_root=0xbfa047e4,
>> path_to_db=0xbfa007e0, path_to_music=0xbf9fe7de,
model_filename=0xbf9fa7da,
>> info_extractor=0x0, flags=67174400, instance=0xbfa097fc,
>> progress_proc=0x804a9b0 <database_progress>, error_proc=0x804adc0
>> <easyh10_error>)
>> at ../common/easyh10_database.c:737
>> #5 0x0804bfab in main (argc=6, argv=0xbfa098b4) at main.c:1108
>>
>> The filename was kinda broken, at least it wasn't latin1, as I specified
>> with --encoding=ISO-8859-1
>>
>> I don't know why, but the previous version didn't crash on this.
>>
>> Cheers,
>> Carsten
>


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to