본문 바로가기

카테고리 없음

id3tag

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.


ID3 tag

MP3 파일에서 사용하는 메타 데이터 포맷으로, 음악의 제목, 앨범명, 아티스트 등의 음악파일에 관련된 정보를 담는다.
ID3는 v1과 v2두가지 버전이 있으며 서로 호환되지는 않는다.

MP3 파일 형태

ID3v2 | ID3v2 | MP3 Data | ID3v1

ID3v1

ID3v1은 1996년에 에릭 켐프(Eric Kemp)에 의해 고안되어 사실상의 표준이 되었다. ID3v1은 파일 끝에 128 바이트를 덧붙이는데, ‘TAG’라는 문자열로 시작되므로 미디어 플레이어가 쉽게 인식할 수 있다. 초기의 MP3 재생기는 때때로 MPEG 스트림 사이에 삽입된 데이터에 적절히 대응하지 못하고, 재생을 멈추거나 잡음이 튀는 등의 문제가 있었고, 심지어 재생을 못하기도 했다(태그가 파일의 첫 부분에 있는 경우). 이 같은 문제 때문에 태그는 보통 파일의 첫 부분보다는 끝에 삽입됐다.

ID3v1 포맷
오프셋 길이 설명
0 3 "TAG" 인식 문자열
3 30 음악 제목 문자열
33 30 가수(음악가) 문자열
63 30 음반 문자열
93 4 음반 출시년도 문자열
97 30 비고 문자열
127 1 장르 바이트[* 1]
  1. 원래 규격에는 0부터 79까지 80개 값에 대해서만 정의되어 있었지만, 윈앰프에서는 이 정의를 147까지 확장했다.

ID3v1.1은 1997년미하엘 무췰러(Michael Mutschler)에 의해 ID3v1의 확장으로 고안된 것으로, ID3v1의 128 바이트를 유지하면서 곡 번호 정보를 추가했다. 이 새 필드는 비고 필드의 끝에서 두 번째 바이트에 위치한다.

ID3v1.1 포맷
오프셋 길이 설명
0 3 "TAG" 인식 문자열
3 30 음악 제목 문자열
33 30 가수(음악가) 문자열
63 30 음반 문자열
93 4 음반 출시년도 문자열
97 28 비고 문자열
125 1 바이트 분리자 (항상 0)
126 1 곡 번호 바이트
127 1 장르 바이트

ID3v1과 ID3v1.1의 규격은 모든 문자열이 ISO 8859-1부호화(인코딩)된 것으로 간주한다. 그러나 많은 프로그램들이 서유럽 외의 언어를 지원하기 위해 시스템의 기본 인코딩을 사용한다. 규격상 인코딩에 대한 공통적인 처리 방식이 없기 때문에, 서로 다른 인코딩을 사용하는 시스템 간에는 인식을 제대로 하지 못하는 문제가 생길 수 있다. 또한 ID3v1 규격에는 모든 문자열의 끝에 남는 공간에는 널 문자를 채우도록 되어 있지만, 윈앰프와 같은 일부 프로그램들은 공백 문자와 같은 다른 문자를 채우기도 한다.

ID3v2
ID3 v2에서는 ISO-8859-1 (이것은 한국어에는 쓸 수 없지요), UTF-16 with BOM, UTF-16BE, UTF-8을 지원합니다.

ID3v2는 새로운 메타 정보에 대한 필요가 생겼을 때 대응할 할 수 있도록 가능한한 유연하고 확장에 용의하게 설계되었다. 이를 위해 ID3v2는 프레임(frame)이라 불리우는 여러 정보 덩어리들을 담는 컨테이너의 역할을 한다. 모든 프레임의 포맷이 그것들을 조우하는 소프트웨어에게 알려질 필요가 있는 것은 아니다. 각 프레임은 미리 정의된 자기만의 명칭(identifier)과 크기 지시자(size descripter)로 시작하는데, 이 정보로 소프트웨어는 자신이 모르는 프레임이 있을 때 해당 프레임과 플래그 필드 하나를 무시하고 지나갈 수 있다.

ID3v2 내의 비트순서(bitorder)는 최상위비트(MSB) 우선이다. 여러 바이트를 사용하는 숫자의 바이트순서는 최상위바이트 우선이다. (예를 들어 $12345678은 $12 34 56 78로 인코드될 것이다.) 이 방식은 빅엔디안(big endian)과 네트워크바이트순서(network byte order)로도 알려져 있다.


태그의 전체 구조는 다음과 같다.

     +-----------------------------+     |       헤더 (10바이트)         |     +-----------------------------+     |          확장 헤더             |     |     (가변 길이, 불필수)       |     +-----------------------------+     |     프레임들 (가변 길이)       |     +-----------------------------+     | padding (가변 길이, 불필수)   |     +-----------------------------+     |  footer (10바이트, 불필수)    |     +-----------------------------+
ID3v2의 첫부분은 아래와 같은 10바이트 태그 헤더이다:
     ID3v2/file identifier      "ID3"     ID3v2 version              $04 00     ID3v2 flags                %abcd0000     ID3v2 size             4 * %0xxxxxxx
 
ID3v2 플래그 필드(flags field)는 버전 뒤에 나오면 현재 4개가 쓰이고 있다.


a - Unsynchronisation(반동기화?????)

'ID3v2 플래그'의 Bit 7은 unsynchronisation가 모든 프래임에 적용되는 아닌지 가리킨다. (자세한건 [http]아래 설명); 표기되면 사용한다는 뜻이다.


b - 확장 헤더(Extended header)

두번째 비트(bit 6)는 헤더뒤에 확장 헤더가 있는지 없는지 알려준다.확장 헤더는 [http]아래에서 설명한다. 표기되면 확장 헤더가 있다는 뜻이다.


c - 시험용 지시자(Experimental indicator)

세번째 비트(bit 5)는 시험용 지시자로 쓰인다. 태그가 시험용 일때는 이 플래그가 표기되야(SHALL) 한다.


d - 끝맺음(Footer present)

Bit 4는 태그의 끝임을 말하는 끝맺음을 가리킨다. 표기되면 사용한다는 뜻이다.

사용하지 않는 플래그는 %0000 이어야(MUST) 한다. 만약 그렇지 않으면, 플래그의 기능을 모르는 파서는 태그를 읽지 못 할 수도 있다.

ID3v2 태그 크기는 28bit의 유효한 크기를 가진 32 bit synchsafe integer로 저장된다. (최대 256MB = 2의 28승).synchsafe integer는 [http]아래에서 설명한다.

ID3v2 태그 크기는 unsynchronisation뒤의 확장 헤더, 패딩, 프래임의 합이다. 만약 끝맺음(footer)를 사용하다면 크기는 (전체 크기 - 20) 바이트이고, 사용 안하면 (전체 크기 - 10) 바이트이다.
 

ID3v1은 그 크기가 128바이트로 정해졌기 때문에, 추가적인 정보를 넣는 것이 거의 불가능했다. 이 문제를 해결하기 위해 Lyric3과 같은 다른 포맷이 제안되기도 하였으며, 마틴 닐슨(Martin Nilsson)이 제안한 ID3v2 태그 포맷도 이런 문제를 극복하였다. ID3v2 태그 포맷은 다음과 같은 특징을 가지고 있다.

  • 파일의 첫 부분에 큰 데이터 블록으로 삽입되며, ID3v1과의 호환성이 없다. (ID3v2.4부터는 선택적으로 파일의 끝에 삽입할 수 있다)
  • 프로그램이 파일의 끝까지 읽어 들이기 전에 태그 정보를 얻을 수 있기 때문에 스트리밍 파일을 재생할 때 이득이 된다.
  • 태그의 길이가 변경될 경우 전체 파일이 재작성되어야 하기 때문에 태그를 쓸 때 효율성 면에서 불리할 수 있다. 이런 이유 때문에 ID3v2 태그 뒤에 적당한 공백을 넣어서, 태그의 길이가 어느 이상 커지지 않으면 전체 파일을 재작성하지 않는 방법을 사용하는 경우도 있다.
  • 몇 개의 고정된 필드를 제공했던 ID3v1과는 달리, ID3v2 태그는 포맷이 정형화된 태그 프레임들로 이루어져 있기 때문에 확장하기 용이하다.
  • 작사자, 지휘자, 매체 종류, BPM, 가사, 이미지, 볼륨, 잔향 설정, 암호화된 정보 등과 같은 다양한 정보를 넣을 수 있다.
  • 태그에 가짜 동기 신호가 삽입되는 것을 방지하기 위한 비동기화(unsynchronisation) 옵션을 제공하기 때문에, ID3v2 태그가 삽입된 MP3 파일은 ID3v2를 지원하지 않는 프로그램에서도 안전하게 재생할 수 있다.
  • 태그 전체의 크기는 256MB까지 허용되며 프레임 하나의 크기는 16MB까지 허용된다.
  • 유니코드를 지원하므로 국제화된 태그를 이용할 수 있다. 기본적으로 UTF-16 인코딩을 지원하며, 또한 ID3v2.4부터는 UTF-8을 지원한다.

ID3v2에는 다음과 같은 세 가지 버전이 있다. 각 버전들은 구조가 비슷하지만 서로 호환성은 없다.

  • ID3v2.2 (1998년): ID3v2 태그의 첫 버전으로, 현재는 거의 사용되지 않는다.
  • ID3v2.3 (1999년): 태그 프레임의 속성을 나타내는 필드가 추가되었으며 확장된 헤더를 제공한다.
  • ID3v2.4 (2000년): 확장된 헤더의 구조가 바뀌었고, 푸터를 지원하므로 파일의 끝에도 삽입할 수 있다. 또한 UTF-8 인코딩을 지원한다.

ID3v2는 너무 많은 정보를 하나의 메타 데이터 포맷에 담기 때문에 구현이 힘들다는 단점을 갖고 있다. 예를 들어, 오디오의 길이를 저장하는 TLEN 프레임과 오디오의 인코딩 방법을 저장하는 AENC 프레임 등은 메타 데이터가 담긴 파일을 분석해도 알아 낼 수 있는 정보이며(다만 경우에 따라서 오디오의 길이를 쉽게 알 수 없는 경우는 있다), ID3v2.4에 있는 84개의 프레임이 각각 서로 다른 내부 구조를 갖고 있으며 버전마다 구조가 다른 경우도 있기 때문에 일괄적인 처리가 힘들어진다. APEv2와 같이 나중에 만들어진 메타 데이터 포맷은 내부 구조를 통일하여 이런 문제를 해결한다.

 




ID3v1 ID3v2 비교
v1은 뒤에 정보가 붙고 TAG로 시작
128바이트의 제한된 공간에서서 사용가능

v2는 앞에 붙고 여러개가 올 수 있다.
ID3로 시작하며 256메가바이트내에서 자유롭게 저장가능
 



글자가 깨지는 문제의 원인

아주 오래 전에 리핑해서 id3 v1을 쓰는 경우: id3 v1은 문자 인코딩을 지정할 방법이 없습니다. 따라서, 한국어는 EUC-KR, 일본어는 Shift_JIS (혹은 EUC-JP), 서유럽 언어는 ISO-8859-1을 간체 중국어는 GB2312/GBK 등 '구식 인코딩'을 썼습니다. 드물게 UTF-8을 쓴 경우도 있겠지요. 어느 경우든 인코딩 지정 방법이 없기 때문에 임의로 쓴 인코딩을 감지하지 않는 한 한글은 깨질 수 밖에 없습니다.


id3v2 태그를 쓰지만, 표준을 어긴 경우.
 

해결 방법

표준으로 ID3tag를 넣는다.
인코딩 형식 감지해서 맞게 표시해준다.