E D R , A S I H C RSS

Wave 파일 열화 논란

last modified: 2015-02-06 18:22:09 by Contributors

오디오 파일(*.wav)을 여러 번 복사하는 과정에서 음질이 열화된다는 주장과, 이를 터무니없게 생각하는 사람들 사이에서 벌어졌던 인터넷 상의 논쟁.

그 자체는 어이없는 해프닝일지도 모르지만 500만원이라는 거금이 걸린 내기 제의로 인해 큰 관심을 받았었다.


Contents

1. 발단
2. 내기
3. 참고


1. 발단

일의 발단은 '뻥쟁이김이사(닉네임)'가 만든 오디오 커뮤니티인 Reference club의 그의 글이었다닉값한다.

Wave 파일의 경우, 우선 리핑 이전에는 CD에 아날로그 형식으로 기록되어 있는 디지털 신호[1] 이며, 이를 리핑하는 과정에서 순수한 디지털 신호로 바뀌어 저장된다. 이를 복사하는 과정에서 데이터 에러가 일어나 binary 레벨에서 차이가 발생하지 않는다면 복사 전후의 파일 자체는 같다.
하지만 지금은 삭제되었으나 #이 글에서 '뻥쟁이김이사'는 다음과 같은 말을 한다.

재미난 건 CD에서 추출한 wave파일을 이리저리 카피하거나 인터넷 다운로드를 거치면서 음질적인 손상이 일어난다는 점이다.
물론 이러한 사실을 알만한 분들은 이미 다 알고 있을 거다.
뻥쟁이 역시 회사 프로젝트의 일환으로 테스트를 해 보았기 때문에 여러 번 카피를 거친 음원파일에 손상이 일어난다는 걸 알고 있었다.
혹시라도 이런 사실이 믿기지 않는 분들은 직접 테스트를 해 보시라.
30~40번쯤 카피를 거치면, 제아무리 당신이 똥귀고 시스템이 단순해도 구분할 수 있는 수준의 심각한 손실이 일어난다.
수십번의 메일 전송이나 인터넷 다운로드를 반복해도 마찬가지다.
뻥쟁이 레퍼런스 정도의 시스템에 음악 좀 들을 줄 아는 분들이라면, 단 한번의 카피본도 구분이 가능할 정도로 손실이 온다.

이쯤 되면 무슨 소리를 하는가 싶지만, 본인은 진지하게 생각하고 있는 듯하다. 바이너리가 같다면 같은 출력값을 가질 수밖에 없으므로, 파일의 변질이 생겼거나 파일이 조각화함에 따라 버퍼링 로스가 발생하여 음질의 저하가 발생할 수도 있다는 나름대로 설득력 있는 의견도 나왔다.

하지만 '뻥쟁이김이사'는 파일 자체의 변조는 전혀 없고, full file buffering을 사용했기 때문에 버퍼링에 의한 렉의 발생 또한 없었다는 말을 추가적으로 댓글로 달게 된다.

거기에 새롭게 원인으로 들고 나온 것은 EMI나 RF, 즉 전자파였다. 파일의 복사 과정에서 발생한 전자파가 컴퓨터 또는 오디오 장치 자체에 영향을 미쳐서 음질이 나빠졌다고 주장하면서, 심지어 기판 회로에까지 문제를 제기한다.

이에 대해 많은 네티즌들이 반박을 하자 '그렇게 자신이 있다면 모니터뒤에 숨어말고 내앞에 나와라' #라는 투의 글을 남기기도 했다.

2. 내기

그 후, '뻥쟁이김이사'의 댓글에서 문제가 시작된다.

나참... 웃기지도 않아서...
그냥 간단하게 하지요.
저는 오디오로 재생되는 음악에 관한한 계측기보다 정확합니다.
그걸 당신이 나서서 정밀 계측기를 들고 저와 싸움을 붙이세요.
이건 좀 예민한 사항이니 500만원빵입니다.
자신 있으시면 ██@██.com으로 연락처 주시고, 자신 없으면 꺼지세요

위와 같은 댓글을 달면서 과연 반응을 예측했는지, 아닌지는 알 수 없지만, 역시나 이에 따른 반응이 즉각적으로 나타나면서 최소 3명 이상의 내기 요청자가 등장한다.
그 중 한 명이 공식적으로 내기를 #요청했고, '뻥쟁이김이사'는 #받아들인다.#2
여기에 공증과 내기 비용을 부담하겠다는 예비 UCC 제작업체(?)까지 가세하면서 #이런 글을 남긴다.

상금을 건 블라인드 테스트를 진행하실 예정이라면 "공개테스트" 를 하는 조건으로
저희쪽에서 내기 자금, 촬영기록 및 공증등을 완전 무상으로 제공할 용의가 있습니다.
내기에서 지실 경우라도 저희쪽에서 자금을 "전액" 제공하도록 하겠습니다.
결국 논란이 된 글은 삭제되었으며, 결말은 운영자가 해당 글 및 댓글 삭제, 회원 강제 탈퇴 등의 신공을 사용하면서 흐지부지 끝나버렸다.

하지만 "뻥쟁이김이사"의 네이버 블로그의 포스팅#을 보면 #Reference club의 최고운영진이 "뻥쟁이김이사"라는걸 알 수 있다. 뭐라고?!?!?!? 빠져나갈 길 따윈 애초에 마련되어 있었던 겁니다 호갱님들

2009년 11월 25일 뻥쟁이 김이사는 12월 초쯤, 테스트를 요청한 사람들의 입회하에 테스트를 하겠다고 선언#

12월 4일 오후 2시 33분, 테스트 결과가 올라왔다. 테스트 결과를 담은 게시물의 캡쳐 스샷(스크롤 주의).

요약하자면 "내가 틀렸다. 하지만 이건 확실히 다른데 어떻게 생각해?"
500만원 내기를 받아들인 바나나(ID명)의 경우 참가 자체도 하지 못한 것으로 보이며, 뻥쟁이김이사 혼자서 진행한 것으로 보인다. 자신의 처음 주장은 틀렸으나, '메모리나 캐쉬가 비워진 상태에서 플레이를 한 첫번째 재생은 동일곡의 두번째 플레이와 차이난다' 라는 새로운 주장을 하고 있는 상태. 이 정도면 Wave 파일 열화 문제보다 더 심각한 주장이다. 마치 과학은 이론이고 저는 실전입니다 라고 주장하는 교강용을 보는 것 같은 기분이 들지 않을 수 없다. 사이비 과학의 표본인가 싶기도 하고...

여담으로 이 '음질 열화'는 시코에서도 은근히 많이 나오는 떡밥 중 하나이다.

3. 참고

발상을 전환해, 중심을 '음원'이 아닌 '컴퓨터 파일' 이라는 사실에 중점을 두고 생각해 보자. 음질이 열화되었다는 것 자체가 파일 카피를 통하여 파일의 내용이 변경된다는 것인데 그럼 같은 DVD로 윈도우 새로 깔 때마다 윈도우가 열화되어 삐꾸된다는 소리. 다른 예로 <하악하악> 텍스트를 인터넷을 통해 배포했더니 몇 번 복붙의 과정을 거치면서 <하늘과 바람과 별과 시>로 변모할 수도 있다는 무서운 이론이다.

다만 무결성을 보장하는 디지탈 전송에서도 오류가 났으나 무결성 검사를 통과할 가능성은 있으며 따라서 이런 일이 완전히 불가능한것은 아니다. 참고로 플래시 메모리에서 정보를 읽어 컨트롤러를 통하여 컴퓨터로 전달해주는 SSD에서의 이러한 오류율 - 복구 불가능 오류율은 최대 10^16 bit 당 1 bit 이다.[2] 물리적 구동부가 존재하는 HDD는 좀더 높아서 10^14 bit 당 1bit 이다.[3] 즉 10 TB 정도의 데이타를 하드에서 읽으면 그중 1bit 정도는 원본과 다를수 있다. 즉 음원 파일이 100 MB 이고 샘플링 주파수가 44.1KHz 라고 가정할때, 10만번 정도 복사하면 4만4천분의 1초 단위의 음 변화가 생길수 있다. 당연히 이런 변화는 아무리 황금귀라고 하더라도 인간이 잡아낼 수 있는 영역이 아니다. 또한 이런 변화가 심하게 생겼을 경우, 디지털 파일은 에러 메시지를 띄우고 실행을 중지시키는 경우가 대다수다. 아날로그처럼 데이터가 심하게 변경된 상태에서도 작동이 되는 것이 아니라는 이야기이다. 그리고 위의 복구 불가능 오류율(URE)도 오해의 소지가 있는 수치이다. 하드디스크 회사에서 내놓는 이 스펙은 해당 장치를 사용해서 몇 비트(바이트가 아니다)의 정보를 읽을 때 잘못 읽을 수 있는 확률을 뜻하나, 실제로는 마케팅적인 의미가 과분히 담겨있는 수치일 뿐이다. 실제로, 2000년대 초반까지만 해도 그 당시의 URE 수치로 봤을 때 현재의 3TB, 4TB 하드 전체를 읽을 경우 20%나 1bit 의 오류의 발생할 위험이 있다고 여겨 RAID 업계가 변할 것이라는 전망이 있었다. 허나 시간이 지나면서 URE 확률은 더욱 낮아져서 2014년이나 그 당시나 하드 전체를 읽을 시 0.xx % 의 확률로 1bit 가 잘못 읽힐 우려가 있다고 하고 있다. 이에 대한 해외의 실험에서도 하드디스크를 몇일이나 다시 읽는 테스트를 반복하여도 아예 오류가 검출되지 않는 상황이다. 즉, 생각보다 현재 쓰이고 있는 하드나 플래시 메모리에 기반하고 있는 SSD 등의 저장매체는 매우 신뢰할만한 수준의 데이터 리드를 보장하며, 상기와 같은 복구 불가능 오류율은 현실적으로 반영이 안되는 마케팅적인 허수임을 유념해야 한다. [4]

이런 것을 주장하는 사람들은 가끔 CD의 염료 성분에 따라서도 음질이 바뀔 수 있으며, 블랙 CD가 가장 좋다고 주장한다. 심지어 CD를 요구르트에 담그면 음질이 좋아진다고 주장하는 사람도 있다.[5]

단, 음악 재생에 사용되는 CD 규격은 리더기의 성능차에 따라 음의 공백이 발생할 수 있다. 손상이나 읽기 오류에 대한 복구 데이터가 없다고 적다고는 하지만 복구용 패리티는 오디오 CD에도 다 있다. 단 수준이 주민등록번호 마지막 자리 수준. (즉, 단위 데이터 길이 당 안 읽히는 데이터가 하나만 있으면 복구 가능하다.) 이 부분은 1990년대 관련 키보드 배틀들 읽어보면 나옴. 컴퓨터용 ODD가 음감용 ODD보다 리딩 능력이 고성능이기 때문에, 원본을 잘 읽어내서 곱게 새로 구운 CD가 CDP에서 툭툭 튀는 흠집난 원본보다 질이 좋게 들리는 것은 가능하다.[6]
참고 자료 : http://parkoz.com/ce_aaye

  • 160만원짜리 음악용 PC(?)# : 사기다. 외장형 USB-DAC[7]나 광출력 사용을 전제로 한 제품으로, PC에서 나오는 디지탈 음원은 어느 PC이든 데이터 무결성을 보장하며 음질은 DAC단에서 결정되므로 음질과는 아무 상관도 없다. 당연히 DAC는 따로 사야된다. 주요 부품들은 저가형 제품[8]으로 도배를 하고(컴퓨터가 느릴수록 더 음질이 좋댄다.하지만 실제로 컴퓨터가 느릴 경우 AAC,OGG Vobis,APE같은 포멧을 재생하기 힘겨워하거나 버퍼 언더런의 영향으로 음질이 안좋아진다.음감을 위해 컴퓨터를 느리게(대부분 느리다기보다는 발열이 적은 쪽에 초점이 맞혀질 것이다.) 사는 것은 결국 무소음 컴퓨터를 위한 거지 음질과의 직접적인 관련이 있어서 사는게 아니다.) 케이블이나 usb단자 등에 과도한 투자를 한 황당한 제품. 본 항목의 내용과 마찬가지로 하드디스크에서 출발한 디지털 음원 데이타가 PC내부에서 흐르는 동안 의도치 않은 변조를 거쳐 usb나 광출력단자로 나올 때는 원본 음원과는 달라진다는 황당한 개소리이론으로 기존의 디지털 데이터 무결성 메커니즘을 완전히 부정하는 제품. 심지어 램의 방열판 유무도 영향을 끼친댄다.

관련항목
----
  • [1] 황당하게도 이 논쟁은 논쟁자가 이 문장의 어디에 방점을 찍고 있느냐가 문제가 된다. 아날로그냐, 디지털이냐. 그 이전에 이게 논쟁인지는...
  • [2] http://www.seagate.com/www-content/product-content/seagate-laptop-fam/600-ssd/ko/docs/600-ssd-data-sheet-ds1780-1-1304kr.pdf
  • [3] http://www.seagate.com/files/www-content/product-content/barracuda-fam/desktop-hdd/barracuda-7200-14/ko/docs/desktop-hdd-data-sheet-ds1770-1-1212kr.pdf
  • [4] 단, 디스켓이나 테이프 백업장치 등에서는 오류가 잘 발생하기 때문에 해당 스토리지에서는 감안해야 하는 수치이다. 현재의 일반 유저들로서는 거의 체감이 불가능하다는 뜻.
  • [5] CD-R의 염료 성분에 따라 CD의 수명이 다를 수는 있으며, CD 표면에 긁힌 자국이 있으면 읽기 오류로 그 부분에 노이즈가 생길 수도 있고, 바나나와 치약을 사용하여 이 긁힌 자국을 어느 정도 없앨 수 있기도 하다. 하지만 그런 물리적인 손상이 아니라면 비록 싸구려 CD-R을 사용한다고 해도 음질이 열화될 리는 없다.더구나 고등학교 물리1 교과서에서는 CD의 일부를 잘라낸 다음에 재생하는 실험(...)이 나오는데,결론은 재생이 잘 된다이다.즉,일부 정보의 손실이 있더라도 음질이나 음악재생에 큰 영향을 끼치진 못한다. 한마디로 개소리. 차라리 싸구려를 사용하면 보존성이 낮다거나, 저속으로 레코딩하는 것이 좋다거나 하는 이야기라면 어느 정도 납득은 가지… 아무리 파일의 복사가 많아도 CRC 나 MD5 값이 바뀌는 경우는 없다. 실험을 할 때에는 정확한 MD5 계산기로 실험하도록 하자.
  • [6] 물론 여기서 MP3CDP같이 음악 파일이 담긴 CD를 재생하는 경우는 제외된다. 이건 CD-ROM 규격이므로 손상이나 읽기 오류를 체크할 수 있기 때문이다.
  • [7] 디지탈 데이터를 아날로그 신홀로 바꾸어 주는 장치
  • [8] 실제라면 저 정도 스펙의 컴퓨터는 기껏해야 20만~30만원정도다(...).
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2015-02-06 18:22:09
Processing time 0.0905 sec