Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_chacon (Read 54830 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_chacon

Reply #25 –
Oh well, having issues converting tags here... (Windows is in cp932 (Shift-JIS) locale)

EDIT: Turns out one of the combinations I forgot to try worked, but the oddity of ISO-8859-1/15 producing japanese glyphs still remains. It's also very weird since CP1252 *is* ISO-8859-1-compatible (https://en.wikipedia.org/wiki/CP1252), so both should have produced the same output.

EDIT part2:  In case the error was because I didn't put "<system code page>" in preconversion for the ISO-8859-1 try, it actually doesn't matter what I pick for preconversion. The output is *always* the same, even if I pick completely nonsense preconversions; it's as if picking ISO-8859-1/15 tells it to "disable any and all charset conversion":
Spoiler (click to show/hide)

----------------------------------
Original post:


The above image doesn't even make sense; even if ISO-8859-1 was the wrong charset (and/or I was lacking a preconversion) it'd produce random european characters, not japanese glyphs (which is the problem I'm trying to fix!). Picking ISO-8859-15 also produces the same results (well, it *is* 8859-1 + euro). Picking 1252 gives me completely different mojibake, but at least it's european mojibake:


Someone on IRC told me I was doing it wrong and that the "right" way was this:

But the results are the same.

For reference, here are the correct tags (fixed using `mkdir fixed; for i in *mp3; do avconv -i "$i" -f ffmetadata - | avconv -i - -i "$i" -c copy fixed/"$i"; done` (avconv assumes ISO-8859-1 on id3v1 and converts to UTF-8; I'd just have to pass through iconv if it was the wrong charset)):


I've had similar issues when trying to fix Shift-JIS tags when my locale is cp1252 (Western); picking 932 as the original charset would still produce typical Shift-JIS-as-ISO-8859-1 artifacts, and no charset combination would help me.

foo_chacon

Reply #26 –
Quote from: Kovensky on
Oh well, having issues converting tags here... (Windows is in cp932 (Shift-JIS) locale)


Undoubtedly foobar and its add-ons offer some very powerful capabilities but oftentimes the used names and strings are pretty counterintuitive as they are named by programmers. Such strings then are named technically correct, but are not very helpful for the end-user. foo_chacon is such an example, IMHO. There should be two fields for the character conversion, one named "Open as..." and the other "Save as...", so that for example if you have an ANSI 1252 codepage with the typical "♪" type of string you would "Open as" UTF-8 to get "?" and then "Save as" either UTF-8 or your local codepage. In the first case, only 1 conversion is done in total, in the latter case 2 conversions. "Preconversion" doesn't really nail it in case 1 because there is only one conversion in total, and not 2 as the "Pre-" would imply.

foo_chacon

Reply #27 –
Does this plugin not affect filenames? I've got a bunch of broken filenames made from splitting improperly coded cuesheets. I'd split them in foobar and use Winamp to auto-correct the tags because the freedb query in foobar has never EVER worked prior to cuesheet splitting, or after, or on any file in general.

The result is I have proper FLAC tags, but the filename remains unaffected. I've done this to about a thousand files so I'd really prefer not having to copy/paste and rename each individual file.

http://i.imgur.com/xTzvy.png

foo_chacon

Reply #28 –
I'm sorry to necropost but I just wanted to say that this is fantastic.

Re: foo_chacon

Reply #29 –
Wishing a 64-bit version will be available.
 

Re: foo_chacon

Reply #32 –
Yirkha is unfortunately gone and there are no foo_chacon sources. Someone would have to recreate it from scratch.
I can't speak for others but I fail to see the point of such a component, I have no idea where it would be needed when everything has been unicode for decades.

Re: foo_chacon

Reply #33 –
Quote from: Case on
Yirkha is unfortunately gone and there are no foo_chacon sources. Someone would have to recreate it from scratch.
I can't speak for others but I fail to see the point of such a component, I have no idea where it would be needed when everything has been unicode for decades.

Well, here's one use case
X

These aren't proper French diacritics. These come up all the time for me. It may be just old content though.

Re: foo_chacon

Reply #34 –
Quote from: Case on
I can't speak for others but I fail to see the point of such a component, I have no idea where it would be needed when everything has been unicode for decades.
That may be true for the English majority encoding world but for rest of the world especially on non-Latin alphabet-based encoding world, that's far from it. Try to get any European or east Asian songs with their metadata all jumbled up due their metadata not saved in Unicode but a local legacy encoding like Windows-1250, 1251, 1253, etc or Shift JIS, GB 2312, Big5 and others. Good luck trying to read them in all jumbled mess.
I am Limyx826

Re: foo_chacon

Reply #35 –
Not that it affects anything or even matters at all, but all the tracks I have acquired with non-latin characters have always been in Unicode. I haven't got a slightest clue how to find a track in some weird encoding. Only idea that comes to mind is to find some 90's Shoutcast stream and record info from it.

If incorrect encoding really is a wide spread problem for you, how about instead of manipulating the tags to try to fix encoding you try fetching correctly spelled tags from MusicBrainz or similar service?

If I saw this problem and were affected by it, I might be willing to try to create a component to solve it.

Re: foo_chacon

Reply #36 –
Quote from: Case on
Not that it affects anything or even matters at all, but all the tracks I have acquired with non-latin characters have always been in Unicode. I haven't got a slightest clue how to find a track in some weird encoding. Only idea that comes to mind is to find some 90's Shoutcast stream and record info from it.

If incorrect encoding really is a wide spread problem for you, how about instead of manipulating the tags to try to fix encoding you try fetching correctly spelled tags from MusicBrainz or similar service?

If I saw this problem and were affected by it, I might be willing to try to create a component to solve it.
I think generally older songs will be affected. I believe in Europe in the last decade it had moved on to Unicode however in east Asia that's entirely different story. While some more recent songs may be in Unicode, but some sources may not. Due to CJK encoding issue, Unicode may not be universal among east Asia.
I am Limyx826

Re: foo_chacon

Reply #38 –
Quote from: marc2k3 on
If I were in this situation, I'd have no problem with 2 fb2k installs. One 32bit with the original component for fixing up these files and the latest 64bit for listening if you really think you need it.
I did so when the 64-bit version released, but as I told you before there is a crashing problem also the 32-bit works fine as is. So, I did not see the reason to kept two version. Whether is it good to kept both is a different discussion entirely. Nevertheless if a 64-bit foo_chacon exist, migrating everything to 64-bit will be less hassle.
I am Limyx826