제목

글쓴이

일단, 플레이어에 따른 음질 차이는 미신입니다.<br />
무손실 음원은 물론이고, 손실압축의 경우에도 음질의 차이는 인코딩 소프트웨어의 알고리즘에 따르는 것입니다.<br />
같은 음원 파일이라면 어떤 재생 프로그램을 사용 하더라도 디코딩한 wave 데이터는 동일한 데이터입니다.<br />
동일한 데이터를 동일한 사운드 드라이버를 통해 재생하는데 음질 차이가 날수 없습니다.<br />
<br />
물론 DSP 플러그인등을 사용하여 인

같은 컴퓨터에서 서로 다른 재생 프로그램 간의 차이를 느끼셨다면 그건 [음질] 차이가 아니라<br />
재생 프로그램에서 각각 다르게 설정되어 있는 [음량] 차이일 가능성이 많습니다.

디지털이라고 다 똑같은 데이터가 아니라, 음성신호를 처리하는 내부 알고리즘상의 차이 때문에 음질 차이가 나는 걸로 압니다.<br />
<br />
플레이어의 경우 제 경험상 foobar, cplay 가 음질이 좋더군요. itunes 는 해상도는 떨어지지만 부드러운 느낌이었고,거원 제트오디오는 음질이 안습이었습니다. 윈앰프는 예전에는 좀 경질이었는데, 최근 많이 좋아진것 같습니다. 수소오디오나 오디오 어사일럼에서도 플레이어에 따른 음질차이를

결론은 자기자신이 내릴 수 밖에는 없지 않나 생각합니다.<br />
김정래씨 같이 민감하게 들으시는 분들은 확실히 차이를 느낍니다.<br />
못 느끼겠다면 축복 받으신거죠. 그냥 대충들으시면 되니까요.<br />
윈도 음질이 불만이라 리눅스로 갈아탄 불행한 1인이 주절거립니다.

한 말씀 더드리면 운영체계 별로는 Ubuntu Studio, Xubuntu, Windows 7, Windows XP의 순 정도가 될 것 같구요. <br />
cPlay, Foobar 정도일 것 같은데요, cPlay 홈페이지 들어가 보시면 버전별로도 음질이 다르다고 난리들입니다. <br />
다들 저 같이 불행한 사람들이죠! 참고로 Foobar는 김태성씨 말대로 음질차이가 없다는 프로그래머가 만든 겁니다. 그래서 cPlay보다 못한지 모르죠.

"음성신호를 처리하는 내부 알고리즘의 차이" 라는게 인코딩 소프트웨어에는 존재할수 있지만<br />
재생 프로그램에는 차이가 존재할수 없습니다.<br />
mp3 파일을 디코딩해서 다시 음성 신호를 만들어 내는 알고리즘은 모든 프로그램이 100% 동일합니다.<br />
알고리즘이 다르면 재생 자체가 불가능합니다.<br />
<br />
같은 mp3 파일을 A라는 플레이어와 B라는 플레이어가 디코딩하여 음성 데이터를 만들때<br />

물론 플레이어가 별도의 디지탈 프로세싱을 거쳐서 음원에 적극적인 데이터 변조를 한다면<br />
당연히 소리가 달라지겠죠. (리샘플링 포함)<br />
허나 플레이어들이 별도의 플러그인 설정 없이 기본적으로 이런 처리를 한다는 이야기는 못들어 봤습니다.<br />
만약 음원의 후처리 과정까지 염두에 두고 플레이어별 음질의 차이를 논하는 것이라면 차이가 나는게 맞습니다.<br />
차이가 나도 아주 많이 나겠죠.<br />
그러나 그 차

김태성님은 어떤 면에서는 참 축복 받으신 분입니다 ^^<br />
많은 분들이 논쟁을 거듭해 왔던 사안이고, 여기서 싸워봐야 절대 결론 안나옵니다.<br />
저도 논리로 김태성님 이길 생각은 추호도 없고, 다만 김정래님의 판단에 도움드리고자 저의 경험을<br />
들려드렸을 뿐입니다. <br />
플라시보든 뭐든, 들어서 좋은 플레이어를 쓰면 되는 것입니다. 특별이 돈드는것도 아니고 말이죠.<br />
<br />
다만 거원 제트오

김태성씨 말이 대부분 맞다고 봅니다.<br />
하지만 그것만을을 가지고 플레이어를 논하다면 그건 일부분만 보는 거라고 생각합니다.<br />
다른 관점이 존재하는 것이죠.

일례로 가벼운 프로그램이 음질이 좋을 확률이 큽니다.<br />
왜? PC란게 어차피 시분할로 한번에 한가지 일밖에 못합니다.<br />
다만 OS가 멀티태스킹을 사용하여 매끄럽게 처리할 뿐이지만 이는 시간의 예술인 음악 재생에 치명적인 약점입니다.<br />
가볍게 잘 만들어진 재생프로그램이라면 얘기가 달라지지요.<br />
OS단에서 실시간에 가깝게 설정을 바꾸면 이 또한 얘기가 달라지지요.<br />
이걸 지터라고 말하면 또 논란

쩝....<br />
이래서 음질 관련 논의에는 끼지 말아야 하는데...<br />
OS 멀티태스킹 성능까지 나오는군요.<br />
웃어야 할지 울어야 할지...<br />
<br />
결국 DOS용 플레이어가 최강 음질이다 라는 결론이 되는군요.<br />
뻥이사같은 분 끼고 F/W로 구동되는 재생 전용 PC기반 트랜스포터 만들어서 떼돈이나 벌어볼까 싶네요.<br />
<br />
실제 OS단의 디바이스 드라이버를 만드는 직업에

김태성씨가 디바이스드라이버 만드신다니 하나 생각나는게 있네요.<br />
지금 쓰는 사운드카드에서 사용할 수 있는 드라이버가 칩셋메이커 게 있고 카드 회사에서 만드는 게 있습니다.<br />
한마디로 기능은 카드사의 게 좋은데 음질은 영 아니올시다더군요. 솔직히 배신감같은 것을 느꼈습니다.<br />
어떤 사용자가 음질이 다르다고 생각하겠습니까? 그런데 확연히 차이가 있더군요.<br />
그래서 게시판에 썼더니 드라이버랑 음질은 전혀 별

기본적으로 김태성님 말씀에 동의합니다.<br />
문제는 플레이어를 바꾸거나 OS를 바꾸는 과정이<br />
여러 변인을 동시에 바꾸는 경향이 있기 때문에<br />
사용자 입장에서 잘못된 결론을 내릴 가능성이 높다는거죠.

XP는 멀티미디어용 OS로는 태생적인 한계가 있는 OS입니다. 컴퓨터를 하이엔드 음감용으로 사용하려는 경우라면 무조건 배제하고 비스타 이상으로 가야합니다.

드라이버에 따라 음질이 다르다면 그건 디바이스 드라이버에서 데이터를 변조하여 착색이 생겼다는 건데요,<br />
그런 무식한 짓을 할 개발자는 없을거구요, 시간에 ㅤㅉㅗㅈ기는 개발자가 필요없는 부분까지 코딩을 할 이유는 없죠.<br />
아마 드라이버 설치 프로그램에 드라이버 뿐만이 아니라 자기들 고유의 믹서 같은 것들이 포함되어 있을겁니다.<br />
믹서는 음질 악화(다르게 표현하면 음색 변화라고 할 수도 있겠죠)의 주범입니다.<br

음성신호를 처리하는 알고리듬이 같고, 사용자 인터페이스만 다른데 소리가 달라진다고들 하시니...<br />
귀찮게 여러 프로그램 사용할 필요 없이 똑같은 플레이어에 스킨만 바꿔가면서 튜닝하는게 좋겠군요.<br />
실제로 사용자가 보고 느끼는 감각에 따라서 소리가 달리 들리는건 예나 오늘 일이 아니지만요.

단순히 kmixer 만의 문제가 아니고, 멀티미디어 프로세스 스케쥴링에 구조적인 한계가 있습니다.

전동환님의 말씀처럼 플레이어를 바꿀때 다른 요인들이 같이 바뀌는 경우가 많을 걸로 생각됩니다.<br />
음악 재생 프로그램들의 음질 차이를 논하는데 해당 프로그램의 믹서와 자체적으로 적용되는 DSP처리를 <br />
포함시켜야 하는가 하는 의문이 생기네요.<br />
기본 설정대로 프로그램 설치를 했을 경우, 각 프로그램의 재생 설정은 제각각일 겁니다.<br />
제가 음질차이가 없다고 주장하는 것은 프로그램의 믹서나 EQ 설정은 O

음질에 대한 의견이 분분한 점에 대해서 제가 생각하기로는<br />
1) 이론적으로나 실제적으로 플레이어별로 차이가 없더라<br />
2) 이론에 상관없이 실제적으로 다르더라<br />
위의 1,2중의 한 부류가 아니겠습니까?<br />
1번 부류라면 패스, 2번 부류 중 이론과 다르다면 이론에 문제가 있는거겠죠.<br />
어차피 이론은 실제를 설명하고 추가적인 추론을 할 수 있으면 최상인데, 현실을 잘 못 반영한데서야...

참고로 제가 생각하는 OS 및 프로그램 최적 설정은 <br />
리눅스 Real-Time Kernel + RT Scheduling Policy(SCHED_FIFO 혹은 SCHED_RR) + ALSA 디지털 출력입니다. <br />
제가 사용하고 있는 조합이기도 하구요. 실제적으로 음질 상 차이가 많이 납니다. 물론 믿거나 말거나.

....<br />
윈도 보다는 리눅스의 디바이스 드라이버 모델이 훨씬 간결하고 직관적이므로 리눅스에서의 재생이<br />
음질이 더 뛰어날수 있다는데는 동의 합니다만, 리얼타임 리눅스 커널은 다릅니다.<br />
linux RT Kernel 아래에서 구동되는 재생 프로그램은 성능이 더 뒤떨어진다고 봐야 되는데요,<br />
<br />
리눅스의 리얼타임 커널은 커널 자체가 리얼타임으로 돌아가는게 아닙니다.<br />
작은 규모의 리

참고로 위에서 말씀하신 RT Scheduling Policy(SCHED_FIFO 혹은 SCHED_RR)은<br />
리얼타임을 논하면서 언급하시면 안되는 내용입니다.<br />
그것들은 리얼타임 os에서 쓰이는 개념이 맞기는 한데....<br />
리얼타임 안에서의 비 리얼타임 구성 요소라고 할까요...<br />
<br />
예를 들자면 우선순위가 1등, 2등, 3등 이라는 Task가 있을때 리얼타임 시스템에서는<br />
항상 순

넵, 김태성씨 말이 맞죠. 그래서 일반적인 운영체계에서는 한계가 명확히 있으며 그나마 줄이고자 하는 고육 지책에서 나온 것들이죠. 그런제 실제로 들어보고 하는 말씀이신지는 모르겠네요. 거의 한달동안 이 놈의 스켜쥴링 설정때문에 머리가 아픕니다. hrtimer가 FIFO 99, Sound Card IRQ가 FIFO 82, 재생프로그램은 RR, ... 마지막으로 한 말씀만 드리면 "Listening is Believing!"

들어보면 차이가 무지하게 나는데, 실제 들어보신건지 의문스러워집니다. 젊은 엔지니어 분들의 특성이기도 하지요.

하하하 이것 참...<br />
바로위 세분들 참 재미있는 분들이네요.<br />
아마 윗 분들과 foobar abx test 하면 제가 이길거 같군요.<br />
실체를 모르고 어림짐작으로 접근하는건 언제나 한계가 있기 마련이죠.<br />
<br />
RTOS의 기본 개념도 잘 모르시는 분들 같은데,<br />
어린 분들에게 젊은 엔지니어란 말을 듣다니... 걍 웃고 맙니다.<br />
어차피 페이지도 넘어간거 관 두죠.

어이쿠 이런논란이.... 답변 감사합니다~~ ^^

너무 어려운거같군요..... FIFO , round robin.... 오랜만에 들어보는말이네요.ㅠㅠ