ID3 support broken in LAME v3.99.5 ?

@MickJT

Norway + Denmark and Sweden, use the same codepage I think (not keyboard layout that's different). But Germany use a different one, so "Blümchen" that has u with two dots, don't show correct with Norwegian codepage, and so on. It normally just few extra symbols might be different, in west Europa, as it use variations of the Latin alphabet, while east block countries use cyrillic alphabet, so difference it a lot bigger. With a limit of 256 symbols in ASCII codepage, some of ASCII numbers have different glyph in different language, that’s not great if you won't share text or mp3's. Also the words becomes a mess if the wrong code page is used.

That's way UTF8 is used on web pages and XML files and so on, it removes the need for code page's.

And there is china and Japan that has too many glyphs to fit in the ASCII table.

For English people it also tiny issue the "Euro" cash symbol is not present in older code page.

@LiveForIt

Quote:Not quite.

All Western European languages (including German, Norwegian, Danish, Swedish, Spanish, French (except for a few rare characters only found in Latin-9) etc.) can use either the Latin-1 (ISO-8859-1) code page or its newer variant Latin-9 (ISO-8859-15) which includes a Euro sign.

If you are having problems with certain characters between Norwegian and German, it might be because it was written using Latin-9 and read with Latin-1 or vice versa. But both languages could have used the same code page.

See the differences between Latin-1 and Latin-9 here: https://www.cs.tut.fi/~jkorpela/latin9.html

Best regards,

Niels

@nbache

That might be the issue, "using Latin-9 and read with Latin-1 or vice versa.", anyway ASCII is not a perfect format, that was my point, because there is no way of telling what glyphs should be, just from the ASCII text files.

@LiveForIt Quote:
You could probably work it out statistically (with some errors for ASCII texts that are too short), but certainly it would not be pretty to code & test. UTF-8 for the win :)

Please try https://www.sendspace.com/file/8vl429

Set executable bit before running.

This is built using libiconv.a inside libiconv_so.lha on OS4Depot. I also renamed the existing iconv.h in SDK:newlib/include just in case that was going to conflict.

Tags seem to be written OK, but I haven't done any testing with non-ASCII text yet (nor do I know how to with the amiga shell).

Edit: This one looks like it's worse than the other one on the last page. If I try putting "test «» test2" as a tag, it only writes "test ". I assume it needs other iconv specific files and environment variables to work properly. Personally I'd prefer to just upload the last one that writes the tag in raw ASCII.

Edit 2: Link above is without -lunix, but I've tried both. I saw it trying to access /usr/lib/charset.alias once. I tried setting the LANG variable to en_US.UTF-8. Snoopy doesn't show anything of interest. If someone else wants to take a look, please go ahead, otherwise I'll upload the build on the previous page in the next few days.

@MickJT
Could you include your lame sources (with the OS4 makefile) in the lame archive you upload. I was able to compile the sources included with lame 3.98.4 on my X1000 and possibly someone else may want to experiment with the 3.99.5 sources and seek a solution to the iconv issue.

I think there may be one other possibility you could try. Check out SDK:newlib/include/sys/iconvnls.h and you will see that it provides a default path for codesets and locale. There is a remote possibliliy that including iconvnls.h (or a header with the default paths) might make newlib's internal iconv work with lame. I'm not sure if the lame LANG variable should be set if you're trying to use the internal iconv.

If neither the internal or external iconv works, then uploading that previous compile is probably the best you can do.

@xenic

I don't make any changes. I add a stack cookie, that's it. The altivec patch is 3rd party, and if I can get an altivec build reliably working, then I'll include the patch diffs. I'll send you a PM.

Quote:

The internal iconv is what's being used in the build on OS4Depot right now. It just isn't working. Looks like I'll be uploading the version on page 2.

@MickJT
I replied to your PM. I selected save the response in my outbox but it didn't get saved. If something went wrong and you don't get the PM, just PM me again.