meta data changing language

Newbie here. Have had Audacity (2.0.2) for some time but I’m not a heavy user.

Had a strange problem show up this morning and I’m not exactly sure what is causing the problem or where to turn to correct. Hope an answer can be found here.

Have a sizable library of music on a memory stick that I use in the car. Was wanting to do some editing of these files and found this problem for the first time. Looking at the files using Explorer, I can see the meta data and it is in English. Import the file into Audacity and can do the editing or even not do any editing. When I go to export the file and reach the point where the meta data editor appears, all the text is now in what appears to me as being Japanese. If I do save the file (export) and look at the file again with Explorer, the meta data now shows up as Japanese. Since I’m talking a thousand or so files, manually editing the data back to English is not on my list of fun things to do.

Since the meta data can be seen in Exployer and is in English prior to importing in to Audacity, I’m thinking the problem isn’t with the file, memory stick or the fact Kenwood has indexed the files on the memory stick but is with Audacity but I’m sure I could be wrong.

Anyone ever see anything like this and if so, what did you do to correct?

Here are the components in this change of events:
Windows XP SP3
Kingston Data Traveler 8G memory stick, about 40% full.
Kenwood KDC-X395 receiver.

Thanks for the report. I am on Windows 7 64-bit at the moment (English “Format” options in the Windows “Region and Language” Control Panel, Audacity running in “System” language, hence English). I noticed a while ago that 2.0.4 alpha or alpha-debug (our current development builds) show the name of imported files in East Asian characters when viewed in Help > Show Log… .

Do you see that in the log? What are your Windows and Audacity languages set to?

Audacity 2.0.0 to 2.0.3 inclusive do not have the “Unicode characters in the log” problem for me. English metadata in imported files is not changed in those versions, nor in 2.0.4 alpha.

Is it possible you could upload an example song as originally stored on the stick for us to look at - using Dropbox,, or similar?

Note that if the original files are MP3, you will lose quality by editing them and re-encoding as MP3 - if you just want to trim the files or change the volume level, you would in any case be better to use MP3DirectCut or similar: .


Thanks for the reply Gale. I’m a little short on time right now but will get to your requests within the next day or two.

I’ve done some more investigating and now believe at least some of the problem is with using the Kenwood app to index the files. A good portion of the files that were indexed have the file name appended to add a 2 digit prefix number to them. All these files are the ones that I’m having problems with with the language translations in the meta data. The files without the 2 digit prefix, aren’t having any problems with changes to the meta data. As long as I don’t import the file into Audacity, the meta data is OK.

I suspected editing the files I would loose some qlty but accepted that. Thanks for the suggestion to use a different editor.

Have an engagement I have to go to so will get back with another post.

Now back to your questions.

Both the computer and Audacity are set for English.

Took one of the files I’m having trouble with and looked at the log. Within the log I didn’t see any foreign language. What I did see was the mention of about 4-6 fails to find some DLL’s. All were variations on the name AVxxx-5x.dll. Did same for a file I’m not having problems with and saw same fail on same DLL’s. Oh, also saw a fail to find/load FFmpeg libraries on both files.

I’d be more than happy to send you a file but I’m not familiar with the apps you mentioned and not really interested in using another new app for a one time need. Any more conventional way to forward the file?

Update: found and installed FFmpeg for Audacity. No longer seeing failed messages in the log.

Thanks - those messages are not really errors - just a notice that you have not installed FFmpeg.

Importing files that lack numbers in the file names does not stop the Unicode characters appearing in the log for me.

Thanks also for offering a file. Files can be uploaded to and without downloading an application. Perhaps you could try uploading to ?


Sorry its been some time since I last logged on, has been a busy week.

Gale, I do appreciate your comments and wanting to help but the truth is I don’t have a big interest in having to sign up for some service just for one file. Is there no way to get a file directly to you? Not only am I trying to solve an issue for myself but if there is an issue that affects Audaucity, I’d like to help you out as well.

Don’t know what the size limit is for attachments but I’m going to attach one small file I’ve had problems with.

Again, thank you very much for your help.

Thanks for the attachment. The attachment limit is 1 MB.

I can reproduce the problem in Audacity but dBPowerAmp has the same problem too. I don’t think it is anything to do with the problem I have with the Audacity log. The attached file’s metadata is encoded in UTF16 but that is not in itself the problem. I doubt the file name has any bearing on the issue.

Is it possible to upload another example file that does not have this characters problem? If the file is too large, then let me know and I can temporarily increase the attachment limit.

To fix the problem, you could batch save the files in MP3Tag. Merely rewriting the tags with no changes in MP3Tag will let Audacity see the tags in English.

However if you only want to do volume changes and trims (no filtering), you should use a direct MP3 editor which will not re-encode the MP3 files, instead of Audacity.

Gale allows you to send files up to 300 MB with no sign up for either the sender or the person downloading - you may need to dodge adverts :wink:
Free downloads on sendspace are deleted after 30 days.

It appears to be Chinese.
This is a partial translation:

Mie Zhi Pran 㜀䌀✀ Sha

䴀 构词成分。 Ben Ben Zhi Bowl Zhou Yun-a jade piece put in the mouth of the dead upon burial 构词成分。 climbing climbing Zhou he Qing LV LV he 㬀 Mie Zhi 䌀 构词成分。 Zhou climbing climbing in love with

䘀 he Sha Zhi 䄀 Bowl he climb climbing 㜀

Does that mean anything to you?

It appears that the file contains two sets of metadata. Audacity is picking up the Unicode metada.
One solution to the problem would be to use a batch metatag editor to fix the metadata before you open the files in Audacity. (I use “EasyTag” but I think that is Linux only - perhaps MP3Tag can do that? (test on a copy of the files to check that it does not remove metadata that you want to keep).

You mean, with the tag identifiers like TALB also translated? If so, how would Audacity pick those up? There is only one TALB in there.

I already tested, that’s why I suggested it (but I was assuming OP wants English metadata)… :slight_smile:

My Unicode log characters are also detected as Chinese by Google translate. The translation is nonsense - like a long sentence made out of a few words, some of which are slightly related to the English words in the file name.


It’s the “slightly related” aspect of the Chinese characters that makes me think that they are not complete nonsense, but actually exist in the metadata. Google Translate is not very good with Chinese so it is difficult to be sure if the Chinese characters really do mean something or are “random” characters, but I don’t think that they look like random characters. If it were just a quirk of misreading bytes, then I would not expect so many valid Chinese characters to be found. Unfortunately my hex editor does not support decoding Unicode characters, so I can’t actually see the Chinese characters in the binary. However, if I turn off automatic correction in EasyTag then I can see the Chinese metadata.

OK I think we are both correct in different ways. I looked in Hex Editor Neo which I don’t normally use. There is only one set of tags, but the exact Unicode characters Audacity sees are in the null spaces (00) in-between the English characters as seen when you view the file in ANSI encoding. ANSI-encoded metadata does not have these “in-between spaces”.

I thrashed the CPU at 100% on a task then opened the problem file in Foobar2000, then I was able to see the Unicode characters change to English in front of my eyes as it “converted” them.

Saving the file in MP3Tag does not remove the Unicode characters but appears to add other characters to the metadata. Perhaps these indicate to other software how it is supposed to decode the metadata.

I am not sure yet whether these characters really are complete “translations” of the metadata. It looks to me more like some of the characters are in fact common to all UTF-16 metadata and only some of the characters are translations. Hence what the Google translations look like.

Is the Kenwood product Chinese?

It would still be very interested in comparing a file from this product that displays correctly in Audacity.


Files with English names but without any metadata still appear to have Oriental characters in the log, so that isn’t a metadata problem.


I’ll take a look for a small file I’m not having problems with. Kenwood is a Japanese Co so I was making an assumption on the translation. Some characters are the same in both Japanese and Chinese. Chinese and Japanese are harder to guess at if you don’t speak one of those languages, much harder than with Korean.

Have not tried it but if I can’t find a small file I’ll see what happens if I run a file through MP3cut and shorten the file, then see if there are any problems introduced via Audacity using this method. May take a day or two before I get a chance to send you anything. May run an experiment running a file or two that I’m not having problems with and have not been run through the Kenwood app and run through the Kenwood app to see if anything goes haywire.

I’m not having problem with ALL the files that went through Kenwood’s app and none of the files that haven’t gone through Kenwood’s app. Wonder what is happening within the file that causes problems with some files and not others?

Another busy week and I’m still running behind. :smiley:

Gale, you asked if I’d send you another file so here it is. Actually 2 files.

Test file 1 = This file has not been run through the Kenwood app. Metadata is in English. Even appears in English in Audacity. I have about 200 files on a memory stick that haven’t been run through the Kenwood app and so far haven’t found any of them that gets translated in Audacity.

Test file 2 = This file has been run through the Kenwood app. Metadate is in English before opening in Audacity but as soon as Audacity has the file open, the metadata is translated. Have to say some of the files that have been run through the Kenwood app, the metadata is in English before opening up in Audacity and stays in English after opening.

Hope these additional file are of some help tracking down the problem.

Both files have been trimmed to be ~1.5 min long.

Appears I can’t attach both files in same post so will try with a second post.

Here is the second test file. (saw the second file exceeded the 1M limit.)

Thanks, webfoot. The “test file 1” is ANSI encoded so doesn’t have the problem (there are no spaces between the English characters when read in ANSI or UTF-8 encoding). The problem files seem to be UTF-16 encoded.

I’ve asked a developer who has been doing some work on metadata for us if he can take a look.