The VideoLAN Forums

VLC 2.0.8.
Gibberish is in the title bar, the status bar, the play list. It comes from the "Title" metadata of the video.
There are some options to set encoding for subtitles, but none that I know of for this metadata.

In almost every case, this is caused by incorrectly formatted source material. There are some tools to rectify the source files, but they depend on the OS and file format (I cannot give any specific name).

A similar problem also occurs with *audio* (mp3) titles containing Czech characters such as š, č, or ů. I am a U.S. user, but I have recordings of music (classical) by the Czech composer Smetana in which the title metadata contains the original Czech selection names. Mp3tag and Windows 7 (Explorer) display these names just fine, but VLAN 2.1.3 Rincewind won't display them, either in playlist detailed view, or in the "Information" window that I can choose from a drop-down by right-clicking on one the incorrectly displayed playlist items. Instead, I get information from some of the selection's other metadata fields (readable Latin characters, not gibberish), almost as if the Czech characters were being treated as field terminators or invalid data, and then the remaining metadata fields misinterpreted.

Wrongly encoded ID3 tags are common, yes. You need a tool to convert them to Unicode.

Very well; I was wondering then if someone could please point out the error in the Unicode encoding; I'm not afraid to hand-edit the field with my hex editor, if I knew very specifically how to correct the encoding.

Here is the title of one selection in plain text:

Má Vlast for orchestra, No. 1, Vyšehrad

Here is the corresponding hexadecimal code, as lifted from the display of my hex editor as I used it to examine the MP3 file's ID3 record. (In order to be as complete as possible, this selection includes the prefix FF FE codes which seem to mark the beginning of the field, and the suffix "TRCK" characters which seem to indicate the beginning of the following track-number field.) Again, Windows Explorer and MP3tag seem to read, understand, and display this title just fine.
The hex sequence "61 01" in the left half of the second-to-last line of the above extract is being used (rightly or wrongly) to represent the s-with-caron character "š" (U+0161) which I suspect is causing the trouble in VLAN.

Thank you for any insights you may be able to provide as to the nature of any Unicode encoding error that may be present.

I don't know then. That one seems valid.