Re: [Audacity-devel] mp3 file "04 The 7 C's"

[Joel B. <bo...@ho...>]

Gale wrote:

>
> Hi Joel
>
> Summary:
>
> I tried the "utf16.c (implements endianness auto detect + prevent loop).patch"
> on Windows 7 and Ubuntu. Good on Windows, but bad metadata import
> with the test files on Ubuntu.
>
>
> Details:
>
> It works fine on Windows 7 for me - no crash with that infinite_loop
> file, the demonstration MP3 files that produce "Oriental characters"
> on import now have correct metadata, and MP3's that have genuine
> Chinese characters in UTF16 metadata also import correctly.
>
> However on Ubuntu, not so good. The infinite_loop file doesn't crash
> but the metadata import on those demo MP3 files is now much worse
> than the previous version of this patch.
>
> The Track number is correct in Metadata Editor but the other metadata
> fields are entirely "Oriental characters". In your last patch the result
> in Ubuntu was that if any fields were wrong, that field had two
> characters correct followed by unknown characters in a box.
>
> My two test files were "04 The 7 C's.mp3":
> http://forum.audacityteam.org/download/file.php?id=8008
>
> (this is the same file as the subject of this topic)
>
> and "test file 2.mp3":
> http://forum.audacityteam.org/download/file.php?id=8082
>
>
>
> Gale
>
>

==> Hello Gale,

i have re-written the code in a different way, to avoid a suspicious implicit "cast" in the original code of "libid3tag" and also to systematically default to "Little Endian" rather than Big Endian. This is not what is specified in the standard, but this what is always done "in the wild" as stated by a developer on the web!

If this solution still fails on Ubuntu, there must be something going wrong in another routine, and i need a PC under Unix for debuging.

Warning: to check this patch, remember that the whole Audacity project (solution) must be rebuild because "libid3tag" is not included in the linker dependencies. 
When not doing so, the compiler will recompile "utf16.c" but the linker will continue to use the previous binary. I suppose that this is the same on Unix.
(I have fallen several times in this trap!).

Best regards,


Joel


>> ----------------------------------------
>> From: bo...@ho...
>> To: aud...@li...
>> Date: Wed, 21 Aug 2013 00:23:06 +0200
>> Subject: Re: [Audacity-devel] mp3 file "04 The 7 C's"
>>
>>
>> Martyn wrote:
>>
>> | From Martyn Shaw <mar...@gm...>
>> | Wed, 14 Aug 2013 22:15:17 +0100
>> | Subject: [Audacity-devel] mp3 file "04 The 7 C's"
>>> Hmm, it is looking like we have the most recent version already, I
>>> can't find any changes on
>>> https://code.launchpad.net/ubuntu/+source/libid3tag/+branches
>>>
>>> It is also looking like nobody is maintaining it. So I guess the
>>> immediate 'problem' of updating it isn't there. If Joel wanted to
>>> step into the wider arena with patches then that is another story.
>>>
>>> TTFN
>>> Martyn
>>
>>
>> ==> I have submitted the patch to ""https://bugs.launchpad.net/ubuntu/+source/libid3tag/+filebug".
>>
>> The patch has been slightly improved, following information found on Wikipedia about endianness detection in BOM-less UTF-16. The presence of a "space" character in a string resolves any ambiguity. The statistical Ascii charater detection is only used for strings without "space".
>>
>> Here is the text found on "http://en.wikipedia.org/wiki/Byte_order_mark"
>>
>> "Clause D98 of conformance (section 3.10) of the Unicode standard states, "The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian." Whether or not a higher-level protocol is in force is open to interpretation. Files local to a computer for which the native byte ordering is little-endian, for example, might be argued to be encoded as UTF-16LE implicitly. Therefore the presumption of big-endian is widely ignored. When those same files are accessible on the Internet, on the other hand, no such presumption can be made. Searching for ASCII characters or just the space character (U+0020) is a method of determining the UTF-16 byte order."
>>
>> For an eventual commitment, you will find the library patch and the modified "audacity-patches.txt" in attachment,
>>
>> Best regards,
>>
>> Joel
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel