Quod Libet プロジェクトに含まれているタグ エディターである Ex Falso が必要です。 Picard (MusicBrainz タガー) は同じタグ付けライブラリを使用している可能性がありますが、QL が作成したものです。
特に、id3v2.4 をサポートする Mutagen タグ付けライブラリが必要です (「サポート」とは、「強制」を意味します...軍事的に...)。また、文字エンコーディングにも優れており、基本的なスクリプト可能なコマンドライン タグ (mid3v2
) が含まれています。 )。正規化のステップに関する限り、Mutagen はのみ タグを ID3v2.4 に保存します。確かにすべてのテキストを UTF-8 に変換できますが、自分でスクリプトを作成する必要があるかもしれません (mid3v2
ツールのデフォルトは、可能な限り現在のエンコーディングを維持することであり、特定のエンコーディングですべてを保存するように指示できるかどうかはわかりません)。 Mutagen は Python で書かれています。
Ex Falso は素晴らしくクリーンな GUI であり、期待される主要な retag-multiple-files 機能のほとんどをサポートしています。私はそれがインターネット検索の方法ではあまり役に立たないと思いますし、アルバムアートワークでそれがどのようになっているのかわかりません.Quod Libetはそれをサポートしているかもしれません.エクス・ファルソはできます 存在しない可能性がありますが、存在する場合はプラグインでそれを行います。その機能は必要ありませんでした -- 私は EF と mid3v2
を使用しています 再タグ付けのニーズを処理するために協力してください。
誤ってタグ付けされたエンコーディングの特定の選択を修正するスタンドアロン アプリケーションを見つけることはないと思います。 cp1252、UTF-16、および GB-18030 が混在することは非常にまれであり、既存のソフトウェアがそれを自動的に解決できるとは思えません。
そのため、私は Mutagen をダウンロードしてカスタム Python スクリプトを作成し、未知のエンコーディングを修正する方法に関する独自の決定を自動化します。例:
musicroot= ur'C:\music\wonky'
tryencodings= 'gb18030', 'cp1252'
import os
import mutagen.id3
def findMP3s(path):
for child in os.listdir(path):
child= os.path.join(path, child)
if os.path.isdir(child):
for mp3 in findMP3s(child):
yield mp3
elif child.lower().endswith(u'.mp3'):
yield child
for path in findMP3s(musicroot):
id3= mutagen.id3.ID3(path)
for key, value in id3.items():
if value.encoding!=3 and isinstance(getattr(value, 'text', [None])[0], unicode):
if value.encoding==0:
bytes= '\n'.join(value.text).encode('iso-8859-1')
for encoding in tryencodings:
try:
bytes.decode(encoding)
except UnicodeError:
pass
else:
break
else:
raise ValueError('None of the tryencodings work for %r key %r' % (path, key))
for i in range(len(value.text)):
value.text[i]= value.text[i].encode('iso-8859-1').decode(encoding)
value.encoding= 3
id3.save()
上記のスクリプトは、いくつかの前提を置いています:
<オール>エンコーディング 0 としてマークされたタグのみが間違っています。 (表向きはエンコーディング 0 は ISO-8859-1 ですが、実際には多くの場合、Windows の既定のコード ページです。)
タグが UTF-8 または UTF-16 エンコーディングであるとマークされている場合、それは正しいと見なされ、まだ UTF-8 でない場合は単純に UTF-8 に変換されます。個人的には、ID3 が誤って UTF (エンコーディング 1 ~ 3) としてマークされているのを見たことがありません。幸いなことに、ISO-8859-1 は序数バイト値の 1 対 1 の直接マッピングであるため、エンコード 0 は元のバイトに簡単に復元できます。
エンコーディング 0 タグが検出されると、スクリプトは最初にそれを GB18030 として再キャストしようとします。有効でない場合は、コード ページ 1252 にフォールバックします。試すエンコーディングのリストの最後にあります。
cp1251 キリル文字や複数のアクセント付き文字が連続する cp1252 ファイル名のような他のエンコーディングがあり、GB18030 と間違われる場合は、何らかのより賢い推測アルゴリズムが必要になります。ファイル名を見て、どのような種類の文字が存在する可能性が高いかを推測してください?