안녕하세요..neogig입니다. ^^ 이곳에 처음으로 글을 올리게 되네요.. ^^;
부족하나마 저의 지식을 함께 나누면서 서로 부족한 부분들을 많은 분들과
보완하고 싶군요..

먼저, 많은 분들이 조금더 홈레코딩에서 전문적으로.. 자신의 장비나 작업에서
좀더 효율적이구 효과적인부분을 연구하다보면 결국, 다시 원점으로 되돌아
오는 경우가 있습니다. 물런, 저두 그렇구요. ^^; 컴터는 아시다 시피
디지털의 언어를 사용하죠 00,01 이런 이진법으로요. 이런 하나의비트가
더해질때마다 가능한 조합수는 배가 되죠.

사실, 그냥 24비트 32비트의 차이점을 설명하면 무지 간단하죠.. 파형에서
그만큼 많이 쪼개구 들쪼갠다는 차이점인데.. 솔직히 이건 어디가서 가오잡기
쉽거나 욕먹기 쉽죠. ^^;

솔직히, 보통 귀가 좋으시지만 그냥 미디작업하시는 많은 분들은 이런
의미가 별필요없죠.. 음악만 좋으면 되니깐.. 저두 그렇게 생각하구요..
저야..어쩔수 없이 학점 관리때문에 하는거라서.. ㅠ.ㅜ

사실, 비트에 관해 제대로 계산을 하구 연구를 할려면 디지털오디오에
관해 알아봐요하죠. 소리,위상,배음,데시벨,다이나믹레인지, 앨리어싱
심지어, 심리학적 음향까지도요...*o*

아니.. 그러면 우리가 흔히 오디오 관련 장비를 보면 수업이 나오는
16,24,32비트에 대한 건 어떻게 나온거냐.. 이것을 알기 위해선 우린 학교를
다닐쩍 그렇게 증오하구 저주하던 십진법/이진법/16진법을 이해하면
편하겠죠.. (전.,. 정말 저주 했습니다.. 수학을 싫어했거든요.)
설마.. 이진법,십진법을 모르시는 분들은 없으시겠죠.. ^^ 모르시면
지식검색을 활용하세요.~

기본적인 구성조합은
십진수 16진수 이진수

0 0 0
1 1 1
2 2 10
3 3 11
4 4 100
5 5 101
6 6 110
7 7 111
8 8 1000
9 9 1001
10 A 1010
11 B 1011
12 C 1100
13 D 1101
14 E 1110
15 F 1111
16 10 10000
... .... ......
전문적인 도표를 활용하면 편하겠는데.. 이건 지식검색을 해보시면 나오니깐..
일단.정리를 하자면 이진수,16진수는 제곱의 합으로 나타낼수 있는데 이관계를
이용하여 이진수,16진수를 10진수로 변환시킬수 있죠. 그러니깐...

십진수 9=9*(100)=9*(1)=9 십진수
십진수 90=9*(101)=9*(10*1)=90 십진수
십진수 900=9*(102)=9*(10*10)=9*(100)=900 십진수

이진수 1=1*(20)=1*(1)=1 십진수
이진수 1=1*(21)=1*(2*1)=2 십진수
이진수 1=1*(22)=1*(2*2)=1*(4)=900 십진수
이진수 111=7 십진수

16진수 F=F*(160)=15*(1)=15 십진수
16진수 F0=F*(161)=15*(16*1)=240 십진수
16진수 F00=F*(162)=15*(16*16)=15*(256)=3840 십진수
16진수 FFF=4095 십진수

CD의 음질이 16비트,44.1KHz라구 아시죠. 이때 16비트는 오디오 샘플의
비율이죠. 그러니깐 16비트의 이진수는 1111 1111 1111 1111 는 2의 16승
가지의 경우 즉..이건 65535까지의 표현을 할수 있죠. 그러면 16비트는
1 0000 0000 0000 0000 = 65536이 되는데 이것을 나누어 보시면 -32,768에서
+32,768을 표현할수 있게 되죠. 이것이 디지털 오디오의 다이나믹
레인지를 결정하는 데이터가 됩니다..

내용이 복잡하게 보이지만 사실, 별꺼 아닙니다. ^^; 제가 이해한걸 보면
쉬운거 당연히..ㅎㅎㅎ 반복하여 읽어보시면 이해하실테니..

아.. 잠이 와서 더이상... 더이상은 못쓰겠습니다. =.= 다음에 차근 차근 위에
말한 순서대로 진행하여 저두 공부정리되구 다른분에게 도움도 되는 기회가
되었으면 합니다.

드디어 한 분이 물꼬를 터놓으셨군요. ^^

DSP를 위한 재료가 되는 데이터 표현 양식(Data Representation)은 크게 두 가지로 나눌 수 있습니다. 그 하나가 고정 소수 또는 정수 방식(Fixed Point, Integer)입니다. 네오님이 써주신 일련의 설명은 이 고정 소수 방식에 해당하는 내용이라 할 수 있습니다.

대부분의 DSP, 프로페셔널 디지털 오디오 관련 장비들은 이 고정 소수 방식을 채택하고 있습니다. 그렇기 때문에 사실상 부동 소수 방식에 대해서는 그다지 알아야 할 필요는 없습니다. 32비트 부동 소수 방식에 대해서 이렇다 할 만하게 자세하게 소개해놓은 문서도 많지 않고요. (있다면 알려주십시오. ^^)

참고로 고정 소수 방식의 디지털 오디오 도메인에서는 큰 이변이 없는 한 비트 수가 다이나믹 레인지와 연관이 되어있습니다. (어림 짐작이 아닌 공식으로 존재하죠.) 보통 엔지니어들은 Bits per 6 dB라고 이야기 하고, 디지털 오디오를 공부하는 학생들이라면 6m (m:빗뎁스)라고 말하겠죠. 여하튼 빗뎁스에 6을 곱하면 대략적인 다이나믹 레인지를 구할 수 있습니다. 하지만, 이것은 '대략적'이면서도 '이론적'인 값입니다. 실제 오디오 인터페이스의 스펙에 나타나있는 값들은 이러한 이론적인 값들 보다는 낮습니다.

고정 소수 방식(Fixed)와는 다르게 부동 소수 방식(Floating-Point)은 도메인 내의 수치 정확성 및 다이나믹 레인지가 월등히 뛰어납니다. 이 부분에 대해서 조금 깊게 알아봐야 할 것입니다. 그 이유는 스타인버그사는 자사의 VST 엔진을 이 부동 소수 방식에 기초하여 만들었기 때문입니다. 자신이 사용하는 DAW가 적어도 어떤 용도에 강하고 어떤 장점을 가지는 지 정도는 알아야 하지 않을까... 해서 저는 이러한 토론 주제를 던져본 것입니다.

다른 분들의 더 많은 참여를 바랍니다. ^^

끝으로 네오님의 좋은 시작 감사드립니다.

에궁..멜빈님이 좋은 글을 써주셨네요. ^^
다시..정신차려서.. 위의 글의 연재를 시작하겠습니다. (헐~ 누구맘대로.. ^^;)

디지털 오디오의 일부분인 비트를 알기위해선 그전에 소리,위상,배음,데시벨,
다이나믹 레인지등등
까지 이해를 하시는것이 제대로된 지식이라 나름대로 고집을 피우고 싶습니다..
사실..당연한거지만.. 더이상 우린 MGR이 되지 맙시다. 마구리..머저리..밀가루..
ㅎㅎㅎ

위에 설명은 기본적인 십진법/이진법/16진법에 대하여 설명했습니다.
그럼, 지금부터 디지털 오디오에 관해 알아보죠..

먼저, 소리는 공기의 진동으로 연속된 에너지의 변화는 파형을 나타내죠..
~~~~ <-- 이런 파형은 위상을 가지고 있구 소리의 세기는 크고 작음을 나타내는
다이나믹 레인지는 db로 측정하죠
여기서 중요한건 많은 분들이 데시벨을 절대 단위로 아시는데 절대적인 단위가
아니라 전류의 세기와 힘의 측정단위인데 음햑학적으론 소리의 세기와 기준이
되는 소리의 세기의 비율로 나타내죠.
자세한건...조금뒤에..

위에 말한 소리의 파형은 위상(phase)을 가지는데 주기적인 파형의 진폭과 이런
파형의 시작하는 점과 끝나는 점의 차이에 따라 사인곡선과 코사인 곡선
(아..그림으로 표현하면 좋은데..)등이 있는데 두파형을 더하면 phase shift될때
합쳐진 파형은 딜레이 효과가 나타나죠. 이것을 이용한 이펙트가 링 모듈레이션이
있겠습니다.

파형이 [일반적인 소리의 속도( 344m/sec)] 440Hz일때 344/440을 계산하시면
0.781818로 나옵니다. 그러니깐 440hz의 소리의 속도는 78cm/sec이되는 셈이죠..
간단하죠..ㅎㅎㅎ

이러한 파형을 가진 소리는 흔히 스팩터럼분석을 해보시면 소리의 주파수 특성을
가지고 있죠
우리가 하모니라 부른는 배음은 정수배의 진동수를 갖는 상음이죠.. 즉..
overtone으로 생각하시면 쉬운데, 기음이라구 해서 목적하는 음과 상음
(oevertone 기음에 결합된음) 이 있구 배음이 있죠

또는 부분음이 있는데 이건 부정수배의 진동수배를 갖는 상음입니다. 이건..
아직 어려워서 설명을 저도 잘 못하겠군요.. ^^; 사실, 위에 말한 기음,상음,배음이
그림으로 설명된걸 보시면 간단한건데. 글로만 표현하자니 어려운 부분이 있군요.

시간나는데로 계속..진행되는 글을 써보겠습니다. 다른분들의 화끈한 참여부탁드려요.~
^^;

일단 고정소수점과 부동소수점의 차이를 생각해봐야겠습니다.
고정소수점은 말그대로 소수점 이하 자리의 숫자 개수가 고정되어 있는 것을 말하구요, 부동소수점은 데이터에 따라서 소수점 이하 자리 숫자 개수가 가변적으로 변하는 것을 말합니다. 따라서 당연히 부동소수점이 좀더 복잡한 계산에 적합하고, 또 그 정확도도 높습니다. 하지만 문제라면 역시 계산 속도가 느리다는 점이겠죠.

여기서 부동소수는 실수 개념으로 처리를 해야만 하구요. 고정소수는 정수만으로도 어느정도 정확도를 가지게 처리할 수 있습니다. 즉, 소수 연산을 정수 연산과 쉬프트 연산으로 대체하는 것이 가능하다는 이야기입니다. 이 부분의 이야기는 컴퓨터 프로그래밍 쪽에서 다루는 이야기이니 깊게 하지는 않겠습니다. ^^ 단지 실수 계산이 정수 계산보다 일반적으로 속도가 느리다는 정도면 되겠습니다.

어쨌든 지금까지의 디지털 오디오에서는 보통 고정소수점을 이용하게 됩니다만, 이제 이것은 좀 예전의 이야기가 아닐까 합니다. melvin님께서 말씀하셨듯이 DAW의 대표라고 해도 무방할 Steinberg의 VST엔진 자체가 이미 32비트 부동소수점 연산(float)을 기반으로 만들어져있구요. (이것때문에 초기VST1.0 시절에는 CPU잡아먹는 괴물로 외면받았었고, 지금도 리와이어등에 비해 CPU클럭을 많이 소비하는 모습을 보여주고 있는 것은 사실입니다만) Intel 계열의 CPU에서 정수와 소수의 연산 속도 차이는 없다고 봐도 무방할 정도가 되어 버렸습니다.

그럼 왜 아직도 DSP는 고정소수점, 즉 정수 연산 기반으로 되어 있는 것인가...
그것은 하드웨어 장비들의 한계에서 비롯된다고 볼 수도 있겠습니다. 일단 하드웨어들에 들어있는 DSP칲은 컴퓨터의 CPU에 비해서는 매우 성능이 떨어지는 칲입니다. 즉, 코-프로세서가 아예 존재하지 않는 경우가 대부분이기 때문에 실수 연산 자체가 불가능합니다. 따라서 정확한 계산을 위해 실수를 이용한다는 것 자체가 힘들게 됩니다. 하지만 분명 정수를 더하고 곱하는 정도로는 오디오 효과 등의 처리가 어려운 것이 사실입니다. 그래서 정수연산만으로 이루어진 고정 소수점 연산을 행하게 됩니다. 이 방법은 위에서 말씀드렸다시피 정수끼리의 계산과 쉬프트 연산(이것은 CPU클럭을 거의 소비하지 않습니다)만을 이용하기 때문에 빠른 속도로 처리하는 것이 가능하구요. 또한 소수점 이하 자릿수는 고정되지만 어느정도의 정확성은 가지고 있는 고정소수점 연산을 하므로, 바로 속도와 정확도의 절충점에 서 있는 방법이라고 볼 수 있습니다.

이런 이유때문에 하드웨어 장비들은 고정소수점 연산을 하게 된 것이구요. (당연히 정확도면에서는 부동소수점 연산이 좋습니다) 초기에 컴퓨터 플러그인 형태의 소프트웨어로 이펙터와 같은 장비의 기능들이 이식될 때는 정말 말그대로 '복각'의 원리에 입각하여 이식 작업을 했으리라 예상되고, 또한 초기의 컴퓨터CPU파워는 지금과 같지 않았기 때문에 역시나 정수기반의 고정소수점 연산으로 각 플러그인을 제작했다고 볼 수 있습니다.

하지만 이제는 상황이 다릅니다. 컴퓨터CPU는 발전에 발전을 거듭하여 이미 정수와 실수의 연산속도 차이는 무시해도 좋을 정도가 되어 버렸고 (벤치마킹에 따르면 AMD의 경우는 좀 다릅니다만...) 사용자들 역시 고정소수점의 연산에서 생기는 오차를 인식할 정도의 귀를 가지고 있는 것이 현실입니다. 제 개인적인 경험으로 재생 음질에 많은 영향을 끼치는 인터폴레이터를 제작해본 적이 있는데, 정수기반의 고정소수점 연산일 때와 32비트 부동소수점 연산일 때의 속도차이와 CPU점유율 차이가 전혀 없다고 보여졌습니다. (저는 Intel P4를 쓰고 있습니다) 음질면에서는 고정소수점과 부동소수의 차이도 아니고, 32비트 부동소수연산(float)일 때와 64비트 부동소수연산(double)일 때조차 차이가 확연했습니다. 그래서 지금은 정확도가 필요한 부분부분 64비트 double연산을 이용하고 있습니다. ^^

짧은 지식에 기대서 말씀드렸습니다. 고쳐야할 부분 있다면 가차없이 지적해주세요. ^^

해성님은 앞으로 디지털 오디오 섹션에서 굉장히 자주 뵙게 될 것 같습니다. 앞으로도 좋은 내용의 글을 많이 부탁드리겠습니다. ^^

32비트 부동소수 방식이 정확성 면에서 더욱 우수한 것은 말할 것도 없습니다. 게다가 다이나믹 레인지 또한 무자비하게 큽니다. 고정 소수 방식의 다이나믹 레인지는 24비트의 경우 144dB입니다. 그러나 32비트 부동소수의 경우 약 1500dB이 됩니다.

이러한 훌륭한 장점이 있지만, 가끔은 저 지나치게 큰 다이나믹 레인지가 문제가 되는 경우도 있습니다. 고정 소수 방식을 고집하거나 선호하는 제회사 및 엔지니어들이 주장하는 바는 - 어차피 대부분의 오디오 미디어 들이 재생되는 장비, 최고급 장비들이 144dB의 다이나믹 레인지와 24비트 고정 소수 방식이 가지는 정확성, 해상도로도 이미 충분하기 때문에 고정 소수 방식을 사용한다는 것입니다. 그리고 그런 생각을 가진 사용자들은 32비트 부동소수 방식이 가지는 1500dB라는 다이나믹 레인지를 '실제로 사용되지 않기 때문에 쓸모없게 되는 부분'이라고 생각을 하게 되죠.

실제로 시판되고 있는 대부분의 AD 컨버팅 유닛은 고정 소수 방식을 채택하고 있고, 이를 VST 엔진 내부에서 사용할 수 있는 데이터로 변환하기 위해 변환 과정을 거칠 때 스케일링(Scaling)이라는 작업을 하게 됩니다. 24비트 고정 소수 방식의 다이나믹 레인지와 해상도를 32비트 부동 소수 방식의 다이나믹 레인지와 해상도로 바꾸는 작업이 되겠죠. 어떻게 보면 음질과 가장 직결이 되는 과정이라고 할 수 있겠습니다만, 스타인버그 측이 어떠한 알고리즘에 의해서 스케일링을 하는가는 공개된 바가 전혀 없습니다.

그 뿐아니라 DA 컨버팅 유닛에 전달되기 전에 발생하는 32비트 부동 소수(VST 엔진)- 24/16비트 고정 소수(포스트 마스터 페이더) 간의 변환에서도 디더링이 일어나는가, 디더링 없이 트렁케이션이 일어나는 가에 대한 여부도 개발자의 확실한 답변은 없었던 것으로 기억합니다. 한 때 누엔도 유저 포럼에서 'Dithered Mixer(디더드 믹서)'에 관해 열띤 토론이 있었기도 했습니다만.

그러한 부분이 오히려 오픈 소스로 공개되어 여러 사람이 함께 개발할 수 있는 환경이 된다면, 사실 VST 엔진의 강력함은 한 층 더해질 것입니다. 그러나 자신들이 지금까지 개발한 독자적인 영역을 공개한다는 것이 그렇게 쉽지는 않겠죠. 적어도, 이 분야의 프로페셔널들이 가장 촛점을 맞추어 공격하는 부분이 바로 32비트 부동소수 방식을 채택하고 있다는 점과 어떠한 방식의 스케일링을 하는가임을 생각해본다면, 스타인버그도 보다 심혈을 기울여 이 부분을 프로그래밍 해야할 것입니다.

오늘 가입했는데.. 와. 이런걸 토의하는 곳도 있군요. 재미있습니다.

저도 잘은 모르지만, 제가 알고 있는 바에 의하면.

IEEE에서 규정한 normalized된 floating-point형은 resolution은 single presion(우리가 프로그래밍할때 32bit 부동소수점형, C에서는 float형)이 24bit입니다.
24비트형의 resolution을 가지고 있기 때문에, 실제로 표현할 수 있는 유효숫자는 7자리가 됩니다.
24비트 정수형과 resolution은 같죠.
단지...
dynamic-range면에서는 나머지 exponent가 표시할 수 있는 영역때문에, 훨씬 커지는 거고..

Sonic foundry에서 제공한 Direct X Plugin Development Kit의 문서에 따르면..

IEEE Single Precision 부동소수점 데이터형을 적극 권장한다. 오디오 데이터에 있어서 32비트 부동소수점은 -1.0~+1.0 사이의 값을 갖는다. 이는 24비트 해상도를 가져 일반적인 16비트 CD Audio format보다 더 세밀한 표현이 가능하고, 이펙트 처리등에 의해 sample data의 값이 커지더라도(이를테면 1.0이상 혹은 -1.0이하), 처리후 다시 샘플 데이터값을 감쇄시키면(즉, 볼륨값을 강제로 줄이면) 원래의 해상도 값을 유지할 수 있다.

근데, 이 얘기를 꺼꾸로 생각해 보면..
24비트의 정수형이나, 32비트 부동소수점형이나, 규정된 범위안에서의 resolution이나 dynamic range는 거의 같은 수준 아닌가 하는 생각도 들고, 24비트 정수형의 경우, overdriven되어 자신이 표현할 수 있는 한계값 이상의 샘플 데이터 값을 갖게되는 경우, 어떤 방식으로는 다시 원래대로 값을 복구시킬 수 없다.. 머 이렇게 되는 것 같습니다만..

잘못이해한 점 있으면 알려주세요.

저도 같은 내용으로 이해를 하고 있습니다만,

DSP Guide라는 문서의 514페이지 부터 시작되는 'Fixed VS Floating Point' 섹션에 보면 Precision 면에서 FP 방식이 Fixed 방식보다 더 우수하다는 내용을 담고 있습니다. 이 문서는 거의 DSP 분야의 교과서 같은 존재라 확실하게 신뢰할 수 있죠. Precision과 Resolution의 뉘앙스의 차이가 있다면 어떤 것일까요? :)

그런데, 웃긴 것은 rane사의 라이브러리 중에 'Superior Audio Requires Fixed-Point DSP'라는 제목의 문서가 있습니다. 이 문서는 Fixed Point 시스템이 갖는 장점과 FP 포맷의 단점을 지적하고 있는데, 이 내용안에 거리의 악사 님이 말씀하신 부분이 있습니다. 1500dB라는 다이나믹 레인지는 8bit의 맨티사에서 기인하는 것이며, 실제 수를 나타내는 부분인 24bit는 동일하기 때문에 레졸루션은 다를 바가 없다고 이야기 하고 있습니다.

어떤 장단에 맞추어야 할 진 모르겠지만, 한 쪽에서는 높은 해상도가 장점이라 말하고, 한 쪽에서는 해상도의 차이는 없다고 이야기 하고 있다는 점은 알아두어야 할 것 같네요.

거리의 악사님도 좋은 글 많이 써주세요. ^^

고정소수점 방식이란.. 근본적으로 데이터를 다루는 방법은 정수형과 같은 것으로 알고있습니다.
예를들어, 0.1, 0.2, 0.3 .... 0.9 .. 1.0 의 값을 01, 02, 03, 04... 이런식의 정수형과 1:1로 대응시키는 특정의 변환함수가 존재하는 데이터형으로 알고 있습니다.
이렇게 변환함수가 고정되므로, 소수점의 위치 또한 특정위치에 고정되어 있을 수 밖에 없고, 데이터를 해석하는 방법으로 변환함수가 사용될 뿐, 실제로 연산은 정수형과 동일하기 때문에, 부동소수점의 연산과는 비교할 수 없을 정도로 단순하므로, 처리 속도가 빠를 수 밖에 없는거.. 이런식으로 알고 있습니다.

다이나믹 레인지라는 것이, "실제 표현가능한 수의 범위"라는 의미고, 해상도(resolution)은 "구분 가능한 최소의 데이터 차이"로 해석한다면, 어떨까요?
그런데, 문제는 디지털 오디오는 출력시에 아나로그 전압범위가 정해져 있고(음.. 정확히 기억은 안나는데... 일반적으로 0~5 V 사이던가요? -_-; 정확히 모르겠군요..), 디지털 오디오 데이터의 다이나믹 레인지가 이 범위를 커버하게끔 해석해야 한다면, 결국, 다이나믹레인지는 어떤 의미에서는 해상도와 유사한 의미를 같는다고 생각이 됩니다만...

재미있는 저의 경험 하나..

VST plugin은 내부에서 사용하는 디지털오디오의 데이터형을 single precision floating point형으로 간주하고, -1.0과 1.0을 0 dB로 생각합니다. C언어에서는 float형이라고 하는 바로 그 데이터 형을 사용하되, -1.0과 1.0을 의미있는 최대 값(이 값 이상의 값도 가능하지만, 이 값이 넘어서면 디지털 오디오 데이터로는 clipping된 것으로 생각)으로 여기는 거죠. 이는 steinberg 뿐만 아니라, Microsoft사 등이 사용한 RIFF Wave(일반적인 *.wav파일)의 WAVEFORMATEX 헤더에서 format이 FORMAT_IEEE_FLOAT 값을 갖는 바로 그 표준과 동일합니다.

다음은 표현 가능한 데이터 영역 범위이며, ()안은 C언어에서 사용되는 데이터 형입니다.

8 비트 정수 오디오 : 0 ~ 255 (unsigned char)
16비트 정수 오디오 : -32768~32767 (short)
24비트 정수 오디오 : -8388608 ~ 8388607 ( . )
32비트 정수 오디오 : -2147483648 ~ 2147483647 (int or long)

32비트 부동소수점 오디오 : -1.000000 ~ +1.000000 (float) , 단! -1.0과 1.0은 포함하지 않음.

이렇게 놓고 보면, 음.. float는 1.0이상의 엄청 큰 데이터도 표현할 수 있고, -1.0이하의 엄청 작은 데이터도 표현할 수 있으니까, 32비트 부동소수점으로 표현하면 무지하게 큰 다이나믹레인지를 갖게꾸나.. 하고 생각할 수도 있을 겁니다.
그런데.. 부동소수점도 바보 같아서.. 다음과 같은 연산은

1.0e10 + 1.0 = 1.0e10

같이 되어 버립니다. 원래는. 100000001.0 과 같은 결과가 나와야 하는데.. 그냥 1000000000.0 과 같이 나온거죠. 이는 부동소수점이라도 "유효숫자"에 한계가 있으며 이 유효숫자는 24비트 정수형과 동일한 수준에서 갖추어집니다. 제 기억에는 float형에서의 유효숫자는 7개로 알고 있습니다.

위에서 부동소수점형의 경우, -1.0과 1.0은 포함하지 않는다는 얘기를 적었는데, 이것 역시IEEE_FLOAT형의 표준안인데, 그 이유역시, 이 유효숫자의 갯수와도 연관이 있습니다.
즉, -0.9999999~+0.9999999 라는 건데. 만일 1.0과 -1.0을 포함시키면, -1.000000~1.000000 과 같이 소수점 밑의 자리수가 7개에서 6개로 줄어듭니다. IEEE_FLOAT의 표준안은 결국,

"32비트 부동소수점이되, 소수점 밑의 유효숫자가 7개를 유지할 수 있는 수"

가 되는 것같습니다. 그리고 이 범위 안에서 -0.9999999, -0.9999998, -0.9999997, .... 0.0000000, 0.0000001, 0.0000002, .... 0.9999998, 0.9999999 의 모든 생각 가능한 32비트 부동소수점 데이터값들 가짓수를 세어보면 24비트 정수형과 거의 동등하지 않나 생각됩니다. (머리가 복잡해서 계산못하겠습니다 ^^;, 누가 한번 정확하게 해보시면 ?? ^^;)

또 다른 얘기거리와 의견 , 고견.. 등등 들어보고 싶군요.

제게 더 공부를 해야 한다는 동기를 부여해주셨습니다. :)

아무래도 플러그인을 프로그래밍 하시던 분이라 확실히 내공이 뛰어나시네요. 유효숫자에 관한 이야기는 정말 잘 읽었습니다. 다시 한 번 책을 펼쳐야 할 시간이...

이것은 예전에 누엔도 포럼에서 한 번 읽었던 내용인데 - 그렇다면 누엔도나 큐베이스 같은 VST 엔진을 채택하고 있는 소프트웨어 내부에서 32비트 FP와 24비트 Fixed 포맷의 경계는 어디일까요. 우리가 일반적으로 알고 있기로는 Post Master Fader 부분인데... 그래서 마스터 페이더의 8번 슬롯에는 디더링 플러그인을 써서 투트랙을 뽑는 것이 정석입니다만.

그 전에서 32비트 FP -> 24비트 Fixed(엄밀히 말하면 오디오 카드의 드라이버에서 정하고 있는 스펙이 되겠죠)의 변환이 일어나는 부분에서는 디더링이 적용이 될까요? 그게 아니라면 트렁케이션이 일어나는 걸까요. 혹시 이와 관련된 문서나 참고할 수 있는 정보가 있을까요? 꽤나 음질에 치명적인 영향을 주는 과정이라 생각이 되는데, 스타인버그 측에서도 이렇다 할 답변이 없었던 것 같습니다. 아무래도 VST 엔진 내부의 프로세스를 공개하는 것이니 만큼 쉽지는 않곘죠.

다른 이야기거리 하나 만을 툭 던져놓고 저는 또 사라지겠습니다. :)

vst 엔진이라는 기술용어가 뜻하는 바가 정확히 무엇인지는 잘 모르겠습니다만...

프로그래밍 입장에서 바라보면, VST라는 것은, 기존 윈도우에서 제공하는 COM객체(여기에는 DirectX Plugin 더 정확히는 DirectShow Plugin도 포함되겠죠)와 같이 외부에 특정 인터페이스를 노출하는 하나의 객체입니다.

VST엔진이 VST를 hosting, 즉, "걸어서 쓸 수 있다"라는 기능을 제공하는 DLL이나 실행파일따위를 가리키는 것이라고 한다면... 또하나, ASIO를 사용하는 DLL이나 실행파일이라고 한다면...

ASIO와 VST모두를 해본 제 경험으로는...

대부분의 코딩 블럭에서 32bit float형 디지털 오디오 데이터가 쓰이고, 딱 한군데,

ASIO의 bufferswitch가 호출되는 부분(이 함수는 ASIO드라이버의 제어판에서 설정된 레이턴시의 샘플이 다 재생되어 버리기 바로 직전에 호출되며, double buffering을 합니다)에서

각각의 오디오 카드가 제공하는 실제의 샘플데이터 포맷으로 변환됩니다.

제가 알기로 대다수의 오디오 카드가 24비트를 지원하지만, 24bit ADC/DAC라고 다 똑같은 ADC/DAC라고 할 수는 없겠죠.. 16비트 ADC/DAC보다 못한 24bit ADC/DAC도 있습니다. 어쨌든..

32 bit float형에서 24 bit signed integer형으로 변환됩니다.

참고로 ASIO드라이버가 지원하는 데이터 포맷은 각각의 오디오 카드 하드웨어 제조사가 결정하며, ASIO를 hosting하는 애플리케이션 쪽에서는 단순히

"야, 너 어떤 포맷 지원하냐? 어. 그래 ? 그 포맷만 지원한다고? 음 알았어.. 그럼.. 네 포맷을 일단 32 bit float형으로 변환해서 내가 이리볶고 저리볶은 다음에 다시 네 포맷으로 최종 변환해 던져줄께. 음 이 모든 일을 레이턴시에서 지정된 샘플 길이 만큼 의 오디오가 재생되는 졸라 짧은 시간안에 다 해치워야 하는 거구나. 나 무지하게 바쁘겠다."

라는 식의 일이 처리되는 것으로 알고 있습니다만....

그리고 "truncate"와 "dithering"을 얘기하셨는데.... 음.. 저같은 비교적 초보 프로그래머나 디더링할 때 트렁케이트하는데, 다른 고수들은 별다른 방법을 쓰는지 모르겠습니다. dithering이 24비트->16비트, 16비트->8비트 이런식으로 데이터의 다이나믹레인지를 줄이는걸 의미하는 것이라면, truncate는 dithering의 한 종류가 아닌가요? 32비트 float형을 24비트로 하면, 거의 truncate할 것이 없는 것으로 알고 있습니다.

기본적으로 저는 32비트 float형을 16비트 오디오로 변환을 다음과 같이 합니다.

nSampleData = fSampleData * 32768;

반대로 16비트 오디오로 부터 변환한다면.

fSampleData = nSampleData / 32768 이 되겠지요.

일케하면 -32768 부터 32767까지의 모든 16비트 오디오 데이터는 -1.0~1.0 사이의 값을 갖게 됩니다.
24비트도 마찬가지고, 32비트 정수형으로의 변환도마찬가지겠지요.

nSampleData / (비트의 최대 최소 차이/2) 의 값이 32 bit float 형의 0.00000001 보다 작으면, truncate가 될 것이고, 그 반대면 해상도는 고스란히 유지될 겁니다.

16비트나 24비트 정수형 오디오는 32비트 float형으로 바꾸어도 해상도는 그대로 유지됩니다. 32비트 정수형 오디오는 truncate이 일어나서, 일단 32비트 float형으로 변환한다음, 다시 32비트 정수형으로 역변환하면 원래의 값을 잃어버리게 될 것 같습니다(음.. 머리가 아파서, 정확한 계산은 못하겠습니다).

이렇게 해 놓고 보니까....

꼭 VST 엔진이라는 것이 별거 아니라는 생각이 듭니다.

ASIO를 사용하지 않고, DirectSound + DirectShow Filter(일반인들이 DirectX Plugin이라고 부르는것)의 조합인 평범한(?) 윈도우 사운드 편집기라도, 내부에서의 처리는 VST엔진과 똑같이 하는것이 그리 어려운 일은 아닌 듯 합니다.

아참. melvin이 언급하신 post master fader에 디더링 플러그인을 써서 투트랙을 뽑는다~ 라는 것이.... 어떤 의미인지를 모르겠는데.....

"소리를 듣는다"
와
"디지털 오디오 데이터를 저장/기록한다"
는 다른 의미인 것 같습니다.

"소리를 듣는다"는 것은 제가 위에서 말씀드린 내용인것이고,
"디지털 오디오 데이터를 저장/기록한다"는 최종 기록된 오디오 파일을 따른 데 가지고 가서 틀어도 똑같은 소리가 나게끔 해야 한다는 것이 차이겠네요.

참고로, Wav파일도, 32 bit float형의 샘플데이터로 기록이 가능합니다.
8비트, 16비트, 24비트 오디오 뿐만아니라, 32비트 정수형 오디오, 32비트 float형 오디오, 심지어, 64비트 double형 오디오도 표준안이 있습니다. 읽으면 다 읽는거죠. 문제는 "내가 쓸 오디오 포맷이 무엇이냐"가 아닐까 생각됩니다.

잼나는 이야기 거리가 되었으면 좋겠네요.

제가 모르던 많은 부분들이 커버되어가고 있습니다. 좋은 글 감사합니다. ^^

제가 말하는 VST 엔진이라는 것은 VST Input/Outpu (Connections), VST Mixer, VST Instruments 등의 일련의 유기적인 시스템입니다. VST 시스템이라 부르기도 하고, 굉장히 거창하게 들릴 수 있지만, 글쎄요... 거리의 악사님의 말마따나 스타인버그가 이런 식으로 자사의 DAW 소프트웨어의 심장부를 지칭하고 있으니 저 역시 이러한 용어를 사용하고 있습니다. VST SDK에 명시된 각 오브젝트들의 기본적인 구조와 이 오브젝트들을 사용하고 모듈들을 호출하는 DAW의 코어가 되는 부분을 가리키는 말이겠죠.

다이나믹 링킹 라이브러리를 호출하여 사용하는 것은 VST 시스템의 일부분이 되겠죠. 그리고 악사님이 말씀하신 다음 부분 -
"대부분의 코딩 블럭에서 32bit float형 디지털 오디오 데이터가 쓰이고, 딱 한군데, ASIO의 bufferswitch가 호출되는 부분(이 함수는 ASIO드라이버의 제어판에서 설정된 레이턴시의 샘플이 다 재생되어 버리기 바로 직전에 호출되며, double buffering을 합니다)에서 각각의 오디오 카드가 제공하는 실제의 샘플데이터 포맷으로 변환됩니다."

이 부분이 바로 제가 말씀드린 VST Output이 됩니다. VST 시스템 내에서는 모든 디지털 오디오 데이터가 32bit FP 형태로 움직이며, 내부에서 이런 저런 과정을 겪은 후에 마지막에 오디오 카드로 보내어지는 부분이 바로 VST Output이라는 말이죠. 그래서 이 곳에서의 데이터는 32bit FP 형태가 아닌 오디오카드의 드라이버가 제공하는 스펙(빗뎁스/샘플레이트)로 교체가 된다는 이야기입니다. (이미 하신 말씀을 제가 재탕한게 되는군요? -_-;;)

이미 말씀하신 내용처럼, 오디오 카드의 빗뎁스가 24Bit Fixed라면 - 32bit FP 형태에서 24bit Fixed로 변환되는 것은 거의 트렁케이션이 일어나지 않는다고 한다면, 누엔도의 믹싱시스템에서 음질 열화가 일어나는 부분은 거의 없다는 의미가 되겠죠. 이 과정을 제가 설명을 좀 들을 수 있을까요? :)

그런데 '거의'라는 단어가 가지는 의미가 또 문제가 될 것 같습니다. 아주 조금이라도 트렁케이션이 일어난다면 음질 열화는 반드시 생기는 것 아닐까요? 디더링이라고 해서 음질 열화가 일어나지 않는 것은 아닙니다만 - 도메인이 작아지는 것은 어찌됐든 '손실'이니까요 - 트렁케이션 보다는 인간이 느낄 수 있는 열화가 적기 때문에 사용되는 것이겠죠.

저는 프로그래밍은 C, C++, VC, VB 쪽을 좀 다루어봤습니다. (전공이 컴공이다보니까요.. -_-;) 윈도우 프로그래밍이나 드라이버 프로그래밍 쪽은 전혀 해보지 않았기 때문에 아무래도 좀 생소하네요.

아. 그렇다면 질문이 한 가지 생깁니다. 32bit FP 오디오 포맷이 24bit Fixed와 비교하여 가지게 되는 장점은 무엇입니까? 지금까지의 스토리라면 사실상의 장점은 거의 없는 것이 되는데요. 쓸데 없이 큰 다이나믹 레인지를 가졌어도 더 나은 해상도를 가지진 못하고, 처리 속도도 느리고, 대부분의 AD/DA 컨버팅 유닛이 Fixed 포맷을 기반으로 하기 때문에 스케일링이나 컨버팅도 해야하고...

장점은 무엇이라 생각하십니까? ^^

저야 말로 오랜만에 재밌고 유익한 이야기를 하고 있는 것 같습니다. 이렇게 좋은 글 써주시는 악사님께 다시 한 번 감사드립니다. :)

우선 VST에서 사용하는 32비트 부동소수점형도 결국 24비트의 해상도를 가지고 있습니다. "거의"가 아니라 "똑 같다" 고 생각듭니다. 단 IEEE_FLOAT형의 디지털 오디오 샘플 데이터 표준 표현방식을 지켰다는 가정하에서죠. 상세한 설명은 저 기 밑에 부분에 적어 보았습니다.

장점은 딱 두가지입니다.

(1) 샘플 데이터가 오버드라이브된 상태가 되더라도, 이후에 다시 감쇄시켜주면, 원래의 값으로 돌아오며, 해상도가 유지된다

만일 어떤 16비트 데이터가 대략 한 30,000정도의 값을 가지고 있다고 생각해 보십쇼. 이 값을 3dB올리게 되면 x 2를 해야 할 텐데요..(맞나? -_-;), 그럼 60,000이 되어야 겠지만, 실제로는 16비트의 한계때문에, -5536이란 엉뚱한 값이 되버리며 , CPU내의 플래그레지스터에는 overflow가 뜨게 됩니다. 이걸 나중에 / 2 한다고 원래값으로 돌아오느냐? 절대 아니죠. 하지만, 부동소수점의 경우, 표준 표현방식으로 16비트 60,000을 표현하면.. 60,000 / 32768 = 0.9155273 이고, 0.9155273에 x 2 하면 1.8310546 이 되어 있습니다. 이걸 나중에 / 2 하면? 정확하게 0.9155273으로 돌아오게됩니다.
이게 왜 중요할까 생각하실 수 있겠지만, Cubase와 같은 복잡한 signal flow를 가지고 있는 애프리케이션에서는 하나의 오디오 샘플데이터가 엄청나게 많은 경로를 거치면서 처리가 됩니다. 이렇게 처리하다 보믄 어쩔때는 심하게 오버드라이브 되기도 하고 그러는데, 효과는 그대로 유지하고, 샘플데이터의 의미있는 값도 고스란히 유지하기 위해서는 부동소수점 연산이 여러모로 편리하죠. 정수형으로 연산을 하면서도 이러한 부동소수점 연산의 장점을 사용하려면, guard bit라는 복잡한 방법이 사용됩니다만. 저도 잘 모르고... ^^;... 어쨌든 알고리즘은 복잡해 지겠죠. 또한, 요즘과 같이 부동소수점 연산이 무쟈게 빨라진 CPU 에서는 그다지 좋은 방법도 아니라고 합니다.

(2) 알고리즘 작성이 간단해 진다

8비트 형, 16비트형, 24비트, 32비트형 각각마다 오디오 버퍼에 접근 하는 방식이 다 다르므로, 각각 따로 따로 작성해야 하는 부분이 분명히 생깁니다. 또, 알고리즘을 구현하다 보면, 다음과 같이 정수형 오디오 샘플 데이터가 분명히 부동소수점으로 변환되어서 계산되는 경우가 분명히 생깁니다.

nSampleData16Bit = nSampleData16Bit * 0.3f;

위와 같은 코드는 결국,

nSampleData16Bit = (short)((float)nSampleData16Bit * 0.3f);

의 식으로 처리됩니다. 즉, 우선 nSampleData16Bit를 부동소수점형으로 변환한 다음, 0.3을 곱하고, 결과 같이 부동소수점형이니까, 이를 다시 short형으로 변환한다는 식의 스토리죠. 그런데, 만일, 부동소수점형의 데이터를 사용했다면, 오히려 계산 과정이 더 간단해 지죠.

fSampleDataFP = fSampleDataFP * 0.3f;

위의 경우는 앞의 nSampleData16Bit형의 연산에 비교해서, 정수형->부동소수점형 변환 1번과 부동소수점형->정수형 변환 1 번의 연산이 줄어듭니다. 처리속도가 오히려 빠르죠. 알고리즘 작성하다 보면 이런 일은 무수히 많습니다.
!!! 물론, 연산 전체를 정수형으로 고정시키는 방법도 가능하기는 합니다. 이를 테면..

nSampleData16Bit = nSampleData16Bit * 3 / 10;

이런식으로요.. 하지만, 위의 경우, nSampleData16Bit에 3을 먼저 곱한 다음 10을 나누는데, 만일 3을 먼저 곱했을때, 운이 나쁘게도 nSampleData16Bit의 값이 32767 / 3 한 값보다 큰 경우에는 어떻게 될까요? overflow되겠죠? 결국 연산은 엉망이될겁니다. 따라서 다음과 같이 하는 것을 생각해 볼 수 있을 겁니다.

nSampleData32Bit = nSampleData16Bit;
nSampleData32Bit = nSampleData32Bit * 3 / 10;
nSampleData16Bit = nSampleData32Bit;

즉, 잠깐 32비트 형으로 형변환 한다음, 연산하고 나서, 다시 16비트로 복구시키는 거죠. 물론, 아주 훌륭한 컴파일러는 최적화 작업시에 이러한 일을 자동빵으로 해주기도 합니다만... 어쨌든 일이 복잡하게 꼬일 수 있는 것은 사실이죠. 결국, 부동소수점 연산은 여러모로 일을 간단하게 해 줄 수 있습니다.

단!!! 일반적인 정수형 연산을 부동소수점으로 바꾸는 과정이 필요할 텐데, 이 과정에서 걸리는 CPU의 부하는 요즘과 같이 복잡한 알고리즘을 사용하는 시대에 비유한다면, 그다지 크지 않으므로, 무시할 경우가 더 많습니다(하지만, 어쨌든 정수형을 그대로 쓰는게 더 빠르다면 그걸 쓰는 것도 생각해 볼 수도 있겠지만, 거의 90%이상은 그냥 부동소수점으로 변환해서 하는게 더 빠를거라는 생각이 듭니다).


FP(melvin님께서 쓰시는 거 보니까.. 일반적으로 부동소수점의 약자로 일케 많이 쓰나봐요^^; 나두 따라 써야지~ ^^;)의 경우 디지털 오디오 데이터를 표현하는 표준 포맷으로는 다음과 같이 정해져있습니다(Sonicfoundry의 문서를 옮겨보겠습니다).

The above example is for 32-bit floats. 64-bit doubles (probably overkill, but certainly possible) can be supported by setting wBitsPerSample to 64. Note that while there is only one defined format for 32-bit IEEE floats, there are actually two variants for 64-bit floats defined by the IEEE standards committee. It is best to assume that the 64-bit float format is not portable.

There are two very basic rules when using this new data type:

• The floats (or doubles) are normalized to the range of -1.0 to 1.0
• Overdriven samples are valid and must be bound by the playback (rendering) device

By doing this, more than 24 bits of precision can be maintained, even with an overdriven signal, up to, but not including, a value of plus or minus 2.0. Precision is lost beyond this point, but hopefully that is a result of the user applying too much gain. If you have a chain of plug-ins, one plug-in can overdrive the signal and the next plug-in may cause a gain reduction, bringing it back to a normal range. This obviously has many benefits.


This new format, when used properly, provides very high performance on Pentium (II, Pro) and RISC processors, while preserving more than 24 bits of precision. In addition, the added benefit of using floating point for DSP routines can make designing and developing algorithms much simpler than using fixed point. Significant performance gains are achieved by maintaining floating point values without converting back and forth to integers. Remember that plug-ins will frequently be chained.

Converting to and from the floating point data type is done as follows:

Data Type: Conversion To: Conversion From:
8-bit PCM (Sample ^ 0x80) * 128.0 (Sample / 128.0) ^ 0x80
16-bit PCM Sample * 32768.0 Sample / 32768.0
24-bit PCM Sample * 8388608.0 Sample / 8388608.0

When converting from a floating point data type to a PCM (integer) data type, you must bound the result. The following example converts a float data type sample to a 16-bit PCM value:

float Sample = 0.123456;
long lSample = (long)(Sample * 32768.0)
short sSample;

if (lSample > 32767)
sSample = 32767;
else if (lSample < -32768)
sSample = -32768;
else
sSample = (short)lSample;

The IEEE float data type is also fully supported by Microsoft’s RIFF .WAV file format. Files should be written exactly like compressed audio files, even though the data is not actually compressed. Microsoft provides ample information on compressed audio files with the Audio Compression Manager (ACM) documentation. In addition, there is an example called ACMAPP, which is widely available on most Win32 SDKs provided by Microsoft.

We used to rant and rave about why you should do all your processing in floating point here, but most of you have gotten the idea that we aren’t writing for 486s anymore, so we’ll spare you.

But for those of you who still haven’t jumped on the floating point bandwagon:

Whatever you do, don’t forget this rule: always profile code before making assumptions about performance. If the time required to convert back and forth between floating point and integer values is outweighed by performance increases during processing, then by all means, process integers (or even better, support both and let the user decide). However, before making any assumptions, profile, profile, profile(여기서 profile은 실제로 코드내의 각 블럭이 실행되는데 걸리는 시간을 측정하는 것을 의미합니다).

Looking to the future, we expect plug-ins that work with floating point to consistently equal or outperform plug-ins that work on integer (fixed-point) samples, especially when trying to maintain more than 16 bits of precision.


위 설명을 간략히 줄이면..

- FP의 정상범위는 -1.0~1.0 사이의 범위이다.
- (하드웨어에서 FP의 값을 받아들일 수 있는 경우)정상범위 이상의 값이 하드웨어로 넘어가면, 하드웨어가 알아서 clamping시킨다.
- FP의 오버드라이브 가능범위는 -2.0 ~ 2.0 이되, -2.0과 2.0은 포함하지 않는 범위이다.
- 이 규칙을 잘 지키면, 24비트의 해상도가 오디오 데이터의 오버드라이브/감쇄 과정을 거치더라도, 유지될 수 있다.
- 정수형(즉 고정소수점형)과 FP형중에 어느걸 쓰는 것이 더 처리시간이 빠른가를 실제로 측정해 보고 좋은 넘을 선택하자.

왜 위와 같은 표준을 정했을까.. 생각해 보니, 이해가 되었습니다. 컴퓨터 상에서의 FP는
-2.0 초과, 2.0 미만의 범위에서는 소수점 이하 7번째 자리까지를 표현할 수 있습니다만,
-2.0이하, 2.0이상의 범위에서는 소수점 이하 6번째 자리까지만 표현할 수 있게 되어있습니다.
(IEEE의 표준안으로, Real*4 표기 방식--> 우리가 알고 있는 32bit FP). 즉 의미론적인 해상도가 줄어들죠. 제가 "의미론적"이라고 표현한 것은 2.0이상이든, 그 미만이든, 어쨌든 가수(mantisa)부분은 24비트의 해상도를 가지기 때문입니다. 하지만, 표현범위가 커지므로인해, "소수점 이하 몇째자리까지 표현할 수 있느냐"의 의미에서는 해상도가 떨어진다는 것이죠.

컴퓨터 내에 저장된 32 bit FP가 표시되는 걸 간단히 확인해 봤는데..

float f0Data6 = 0.999999f; --> 0x3f7fffef
float f0Data7 = 0.9999999f; --> 0x3f7ffffe
float f0Data8 = 0.99999999f; --> 0x3f800000 (실제로는 1.0000000임)
float f0Data9 = 0.999999999f; --> 0x3f800000 (실제로는 1.0000000임)

float f1Data6 = 1.999999f; --> 0x3ffffff8
float f1Data7 = 1.9999999f; --> 0x3fffffff
float f1Data8 = 1.99999999f; --> 0x40000000 (실제로는 2.0000000임)
float f1Data9 = 1.999999999f; --> 0x40000000 (실제로는 2.0000000임)

float f2Data6 = 2.999999f; --> 0x403ffffc
float f2Data7 = 2.9999999f; --> 0x40400000 (실제로는 3.000000 임)
float f2Data8 = 2.99999999f; --> 0x40400000 (실제로는 3.000000 임)
float f2Data8 = 2.999999999f; --> 0x40400000 (실제로는 3.000000 임)

위의 결과를 보시면, -1.9999999~1.9999999 까지는 정확히 소수점 이하 7 자리까지가 표현가능하지만, 그 이상이 되면 해상도가 떨어집니다(2.999999는 표현할 수 있어도, 2.9999999는 표현할 수 없는 것을 보면..). 이게 2진수로 소수점을 표현하다 보면 생길수 밖에 없는 현상이고... 아무튼 그렇습니다. 이것은, 조금더 깊숙한 이유때문인데...

Real*4 표준 FP포맷은 실제로 내부에 가수부를 위한 비트를 하위 23bit만 할당하고, 8비트의 127에 bias된 지수부와, 1비트의 부호부로 형생되어 있습니다. 합쳐서 32비트가 되죠. 그런데, 가수부 비트 23비트는 맨 위에 가상의 1비트가 있다고 가정하며, 이 값은 항상 2진수 1이라고 정해놓았습니다. 즉, 23비트의 2진 소수는

(1.)bbbbb bbbbb bbbbb bbbbb bbb

이런식으로 표현되고,

이를 십진수로 옮기려면..

1 * 2^0 + b * 2^-1 + b * 2^-2 + b * 2^-3 ....

이런식으로 계산되겠죠. 예를들어, 1.0000000의 32비트 FP 표현은

0 01111111 00000000000000000000000

이 되고, 맨 앞의 0은 +를 의미하고, 01111111은 127에 bias된 가수부로서, 01111111 값 자체는 127이지만, 결국 0이 되며, 맨 뒤에 00000000000000000000000은 실제로는 이진 소수
(1.)00000000000000000000000(=1*2^0)이 됩니다. 이걸 계산 하면, (1*2^0)*2^0, 즉 1 이 됩니다.

2.000000의 32비트 FP표현은..

0 10000000 00000000000000000000000

이 되는데, 지수부 10000000은 십진수로 128이지만, 127에 bias되어 있으므로, 1의 의미를 갖고, 가수부 00000000000000000000000는 또 역시 앞서 설명한대로 1*2^0 값이 되지요. 결국 (1*2^0)*2^1 이 됩니다.

이런식으로 잘 따져보면, -1.9999999 ~ 1.9999999 사이에서는 32비트 FP의 가수부는 항상 01111111 즉, 십진수 0으로 되지만, 2.0이상, -2.0 이하가 되면, 가수부가 10000000, 즉 십진수 1 이상의 값을 갖기 시작합니다. 이렇게 되면, 32비트 FP의 표현상

(가수부) * 2 ^ (지수부)

와 같이 되어 있어, 가수부의 값에는 무조건 2 이상의 정수가 곱해지게 되어, 십진수로 변환할때 가수부가 나타낼 수 있는 의미론적인 해상도의 값이 점점 증가하게 됩니다.

24비트 해상도를 갖는 32비트 부동소수점이라면서, 해상도가 증/감한다(의미론적으로)는 것이 이상하게 들릴 수 있겠지만, 디지털 오디오라는 것이 결국, 어느 일정 범위의 headroom을 미리 지정해 놓는 다고 했을때, 부동소수점과 같이 소수점이 숫자들 사이를 왔다리 갔다리 붕붕 떠 다니는(floating -_-;) 지수표현형태의 숫자와는 맞지가 않죠. 그래서 Sonic foundry의 문서에서는 범위를 지정해 놓은 것이고, 이 범위 안에서라면, 1.0부터 2.0사이, -2.0부터 -1.0 사이의 숫자로 원래의 숫자가 뻥튀기 되더라도 32bit FP의 특성상 해상도가 고스란히 유지된 체로 gain을 조정하며 원상태로 복구 시킬 수가 있는 겁니다. 이것은 고정소수점이나 정수형 연산에서는 불가능한 것이죠(물론, 앞서 설명한 것 처럼, 16비트 정수->32비트 정수, 8비트 정수->16비트 정수 로 잠깐 형변환해서 연산을 쭈욱 다 한다음 다시 원래의 형으로 최종 바꾸어주는 것도 가능은 하겠지만, 알고리즘/작업방법이 일관되지 못하죠).

32비트 부동소수점 얘기를 하다 보니 또 생각나는 것이 있네요..

바로 "비정규형(denormalized) 수"라는 것인데요... 앞서 설명한 IEEE표준 부동소수점 표기 방식은 "정규형(normalized)"입니다. 정규형과 비정규형을 나누는 것은 23비트 가수부의 맨 앞에 가상의 1 bit의 값이 0인지(비정규형) 1인지(정규형)에 따른 것인데, 비정규형은 보통 지수부가 -127의 값을 가지는 경우에 코프로세서에서 적용된다고 합니다.

예를들어,

(1*2^0)*2^(-128) , 즉, 가수부는 1, 지수부는 -127

의 값보다 더 작은 수를 부동소수점으로 표현하기 위해서는, 가수부에 있는 맨 앞의 가상의 1 bit의 값을 0으로 만들어야 합니다. 그런데, 이렇게 되면, 이 값보다 더 작은 수, 이를 테면

(0*2^0 + 1*2^-1)*2^(-128)

과 같은 수를 표현할 수 있게 되죠. 대신, 숫자가 작아지더라도, 이 경우 지수부의 크기가 더 작아질 수는 없기 때문에, 해상도는 숫자의 크기가 작아질 수로 줄어듭니다. 이게 무슨 큰 이슈거리냐 할 수도 있겠지만, 이런식의 비정규형 표현을 갖게 되는 데이터를 처리하는 방법은 정규형과는 다르며, 연산시 엄청난 CPU부하를 가져오게 됩니다.

Cubase같은 프로그램에서 tailing이 있는 이펙터(대표적인 예가 reverb죠)를 사용할때, play할 때는 CPU소모량이 몇 %안되는데, Stop을 하면 갑자기 CPU가 100%가까이 peak를 치는 것을 보신적이 있나요? 이런 것은 샘플데이터가 지극히 작은 값을 가지고 있어, 내부에서 비정규형으로 변환되어 생기는 겁니다.

너무 길게 얘기되었는데, 죄송합니다.

잼있자나요. ^^; ... 없나? ㅎㅎ

근데, melvin은 이 사이트 관리자이신거 같은데, 뭐하시는 분인지 궁금하네요 흐흐.

또 좋은 얘기 있기를...

이런 좋은 글을 써주시다니... 거리의 악사님의 글은 캡쳐해서 두고 두고 봐야겠습니다. ^^
디지털 오디오 섹션의 수준을 한 껏 올려주시는 군요. 앞으로도 좋은 글 더 부탁드리겠습니다.
원하신다면 디지털 오디오 섹션의 관리자 권한을 드리고 싶네요. :)

저는 개인적으로 이 부분에 관심이 지대하게 많아서 이래저래 자료들을 둘러보고 있는데, 아무래도 기본 이론적인 이야기들은 많지만, 큐베이스나 누엔도 같은 현재 쓰여지고 있는 어플리케이션들 내부의 디지털 오디오 핸들링이나 시그널 패스에 관한 정보는 거의 찾아볼 수가 없는 것이 현실입니다.

제가 누구인지 궁금하시다구요? ^^;

네. 머.. 이 사이트 홀홀 단신으로 만들고 뉴스 기사 쓰고, FAQ, Tip 쓰고... 그리고 이렇게 거리의 악사님과 이런 글 주고 받고 하는데서 희열을 느끼는 룸펜입니다. ^^;

나중에 기회가 되면 오프라인 모임 같은 데서도 한 번 뵈었으면 합니다.

"Cubase같은 프로그램에서 tailing이 있는 이펙터(대표적인 예가 reverb죠)를 사용할때, play할 때는 CPU소모량이 몇 %안되는데, Stop을 하면 갑자기 CPU가 100%가까이 peak를 치는 것을 보신적이 있나요? 이런 것은 샘플데이터가 지극히 작은 값을 가지고 있어, 내부에서 비정규형으로 변환되어 생기는 겁니다."

안그래도 이러한 디노멀라이즈에 관한 버그에 대해서 FAQ 문서를 작성중이었는데, 중요한 말씀을 주셨네요. 리버브 말고도 다이나믹 계열에서도 이러한 버그가 있는 것들이 있었습니다. 이러한 디노멀 버그를 해결하기 위한 임시 방편으로 문제를 일으키는 플러그인의 바로 앞에 디디링 플러그인을 걸어서 디더 노이즈를 넣어, 지극히 작은 값을 일정 수준까지 올려주는 것이죠.

그런데 저도 궁금해집니다. 거리의 악사님은 뭐하시는 분일까요? ^^

저는 대전에 있는 이머시스라는 회사에서 오디오 관련 소프트웨어를 개발하는 일을 하고 있습니다. 지금 제가 하고 있는 제품의 성능은 아직 초라하지만, 언젠가는 훌륭해 지지 않을 까 하고 열심히 하고는 있습니다만.. ^^; 앞으로 직업이 무엇이 되었든 간에, 디지털 오디오와 연을 끊고 살기는 어려운 것 같습니다.

예전에 저는 로직 을 사용해서 미디 시퀀싱을 했는데... 그 전에는 도스용 케이크 워크를 사용했었군요. -_-; 컴음악에도 관심이 많습니다. 요즘은 많이 못하지만..

melvin님과 저만 얘기를 계속 하는 것 같아서 이상하긴 한데... 명색이

24비트와 32비트에 대한 포맷을 얘기하는 란이니까.. 또 지나가는 말로 한가지 하고 싶은 얘기는

고정소수점형(즉 정수형)과 부동소수점형 중, 정확한 연산이 가능한 것은.... 엄밀히 말해 없습니다.
하지만, 연산의 과정중의 데이터 값이 임의의 범위내로 한정된다면, 정확한 계산은 고정소수점 쪽이죠.

부동 소수점은 정확한 연산이 안됩니다. 위에서 제가 설명했던 것을 잘 따져 보다 보면.. 그렇다는 것을 느끼실 겁니다. 더군다나, 코프로세서의 내부 처리는 80비트 레지스터를 사용한다고 하는데(펜티엄에서) 코드 최적화 등에 의해 80비트에서는 정확한 값이었는데, 32비트로 다시 옮겨 오면서 값이 반올림되거나 깎이거나 하는 일도 생기고, 하여간 정확하지 않습니다. 물론, 그 정확하지 않다는 것은 엄청나게 쪼잔한 기준을 두고 하는 얘기죠.

중요한 것은, "효율성"이 될 겁니다. "효율성"은 프로그래머의 입장에서의 효율성도 있고, 사용자 입장에서의 효율성도 있을 겁니다만.... 주로 전자에 기준을 맞춘것이 VST의 기본 컨셉이 아닐까 하는 생각도 들고...
하여간 그렇습니다. 저도 잘 모르는 것이 많구. DSP가 전공도 아니고 해서.. 여기까지가 제가 쓰고 싶은 글은 전부 다 인것 같습니다.

또 다른 주제를 놓고 여기 분들과 얘기하고 싶은데. 그게 먼지 저도 잘 모르겠군요 ^^;

아.. 디노멀라이즈 관련해서 지금은 대다수의 플러그인 개발사들이 펜티엄4에서의 문제점을 파악하고 대부분 다 패치를 한 것으로 알고 있습니다만....

아무튼 조은 얘기 많이 나눈것 같습니다~~

시간이 되면 저도 한 가지 정도의 글을 더 쓰려고 합니다. 24비트 정수형이 32비트 부동소수형에 비해 가지는 음악적인 장점에 대해서요. 요 며칠은 넘 정신이 없어서 시간이 어떻게 지나갔는질 모르겠네요. -_-;

거리의 악사님과 좋은 이야기 나눈 것 같아 저도 기분이 좋습니다.

다음 주제는 AD/DA 컨버터에 관해 이야기를 좀 해볼까 합니다. 소규모 레코딩 스튜디오나 홈스튜디오에서 쓸 수 있는 AD/DA 컨버터는 어떤 것들이 있으며, 어떤 가격대 성능비를 보여주는가에 대해서 여러분들의 이야기를 들어보려는 생각입니다. 홈스튜디오의 심장이 DAW라면, AD/DA는 눈과 귀, 입에 해당하는 가장 중요한 요소중에 하나이니까요. ^^

네이티브 DAW 중에서 POW-r 디더 알고리즘을 갖고 있는 건 세쿠이어가 최초이죠. 세쿠이어나 샘플리튜드도 네이티브 방식으로는 상당히 좋다고 생각하고 있습니다.

좋은 글들 잘 보았습니다. 그나저나
거리의 악사님 이머시스에서 근무하신 다니...
얼마전 이머시스의 외주 음원 작업을 제가 했었는데
더구나 그 회사에는 제 대학 후배 놈이 다니고 있답니다.
안 그래도 개발하신다는 소프트웨어 데모도 잠깐 써봤구여 ..ㅋㅋ
언제 만나뵐 수 있는 계기가 있었으면 좋겠네요 후배놈 한테
물어봐야 겠습니다.
뵙게되면 많은 가르침 바라겠습니다. ^^

오오..뒤늦게나마...이런.. 거리의 악사님과 멜빈님의 토론을 읽고 있노라니...
뜬금없이 궁금하기만 하던 여러부분이 막연하게나마 이해가 되는군요..ㅜ ㅜ
대단들 하십니다요!
새삼스럽게 플러긴이나 호스트시퀀서 등을 만드는 사람들에 대한 존경심이 밀쳐올라옵니다...
저렇게 복잡하게 만드는 것들을... 암생각없이 막 쓰고 있었다뉘..ㅡ,.ㅡ

질문!!

VST 믹서 내부 해상도는 32비트 플릇 . 아웃풋은 들리는것과 저장하는것 2가지로 나뉜다고

이해를 했는데요

그러면 들리는것은 32 비트 플릇이 -> 바로 24 비트 dac 로 나온다는 이야기구

저장하는것은 32 비트 플릇 -> 디더링 플러그인 -> 24비트로 저장

뭐 이런 이야기인가요?

근데 디더링 플러그인은 보니까...선택하는 옵션이 24비트, 16 비트 20 비트 이렇게 있더군요

저도 궁금한게 VST 믹서는 32비트 플릇으로 동작하는데

일단 저장할때는 32비트 플릇 으로 저장가능하니까...상관 안한다쳐도
(24비트나 그이하로 저장할떄는 디더링 플러그인 걸고 저장하니까 그렇다 쳐도)

대체 우리가 모니터링하는 그 소리는 그 32비트 플릇이 뭘로 변신해서 나는 소리인가용?

누엔도에서 자동으로 그데이타를 디더링 없이 24비트(또는 dac 스팩에 맞게)로 바꿔서 출력하는건가요?

그럼 그 차이가 바로 sx1 과 누엔도2(sx2) 의 차이를 만들어낸건가요?

^^ 답변좀~부탁드립니다 어케 생각하시는지~

안녕하십니까. 오랜만에 옵니다.

우선, 32비트 float 오디오 데이터를 믹싱하는 소프트웨어 믹서를 가진 소프트웨어들은 많습니다. 꼭 VST라는 기술을 붙인 steinberg에만 있는 것은 아니죠.

직설적인 답변은 : Analog In --> N bit Audio --> 32 bit float audio 변환 --> plug-in 처리 , 믹싱 등등... 처리 --> M bit Audio 변환 --> Analog out

입니다. 위에서 N과 M 값은 하드웨어 제작 업체에 따라 다르겠죠.

즉, 변환과정은 전적으로 소프트웨어에 의해 이루어지는 경우가 많다고 알고 있으며, 최대 24bit 정수형 까지는 32bit float형으로 변환시에 resolution변화는 거의 없다고 봐야 합니다. 32 bit float형도 24비트 해상도를 가지니까요(특별히 overdriven 되는 경우가 아니면...).

저는 귀가 나빠서 sx1과 sx2의 차이를 잘 모르겠는데... 알고리즘 상으로 이런 데이터 변환시에 손실을 막기 위해 wave shaping이라는 것을 한다고 들었습니다.

그럼. 이만.

Waveshaping은 넌리니어 앰프 이상의 것은 아닌 걸로 알고 있습니다. 그리고 디스토션, 클리핑을 의도적으로 생성해내는 신서시스의 일종입니다. 디지털 오디오 에서의 웨이브 쉐이핑이 다른 의미를 가지는지 아닌지는 잘 모르겠습니다만. 한 번 찾아봐야 하겠군요.

여러분들의 진지한 대화 참 좋군요..

허나, 전 먼가 알듯 하면서도 잘 모르겠네요.

쉽게 말해서 32bit를 쓰는게 좋을까요..24bit를 쓰는게 좋을가요.

전 누엔도에 대부분 vst악기들을 쓰고 있습니다.

바보 같은 글이라 죄송합니다.

오랜만에 이 멋진 토론을 다시 보니 느끼는 바가 있어서 정리할 겸 적습니다. 이전과 비교할 때 지금은 좀더 자연스럽게 이해할 수 있음에 꽤나 희열을 느끼고 있습니다. ^^

확실한 점은 Floating Point 가 Fixed Point 에 비해 분명히 우수하다는 점입니다. 32비트 FP와 24비트 Fixed Point 를 비교하자면, 네, 분명 Resolution은 24비트로 두 포맷이 동일합니다만, Precision 은 FP가 우수합니다. 전에는 이것이 잘 이해가 가지 않았는데... 다음을 보시면 다른 분들께서도 이해에 도움이 되지 않을까 싶네요.

Resolution, '해상도'는, 컴퓨터에서는 '어떤 일정 범위를 얼마나 자세하게 나눌 수 있느냐'의 의미로 쓰입니다.
Precision, '정밀도'는 '얼마나 정확한 값을 표현할 수 있느냐'의 의미입니다.

우선 24비트 Fixed Point 를 생각해보면, 1비트의 부호를 제외하고 23비트의 wordlength 영역에서 표현가능한 해상도Resolution은 2^23 으로, 0 ~ (2^23)-1 이 됩니다. 이를 [0, 1) 범위의 값으로 환산한다면 최소표현단위, 즉 값이 1 변할 때 그것의 실제 의미는 1/2^23 변하는 셈이 되겠고, 1/2^23 은 1/8388687, 즉 1/10000000 = 0.0000001 과 가까운 값이 됩니다. 유효숫자가 7개라는 것은 바로 여기서 나온 말이 되겠습니다. 정확히 7개는 아니죠. 6개보다는 많고 7개보다는 적습니다. 유효숫자는 10진수로 생각하기 때문에 2진수 기준으로 보면 딱 들어맞을 수는 없는 것이지요. 이를 생각하면, 24비트 Fixed Point 의 정밀도Precision 은 1/2^23 이 되겠습니다. 이보다 작은 단위나 값은 표현이 불가능하여 0이 되어 버립니다.

이번에는 32비트 FP를 살펴보겠습니다. 23비트의 가수부가 abc defg hijk lmno pqrs tuvw 라면 실제 값은 다음과 같이 계산되겠습니다.

0.xxxxx 을 나타낼 때에는 지수부가 126=127-1 이 되어 다음과 같은 구조가 됩니다.
(2^-1) * [ (2^0 * 1) + (2^-1 * a) + (2^-2 * b) + (2^-3 * c) + ... + (2^-23 * w) ]

1.xxxx 를 나타내는 범위에서의 지수부는 127=127+0 의 값을 가지게 되어 지수부의 실제 의미는 2^0 이 됩니다.
(2^0) * [ (2^0 * 1) + (2^-1 * a) + (2^-2 * b) + (2^-3 * c) + ... + (2^-23 * w) ]

2.xxxx 를 나타낼 때에는 지수부가 128=127+1 이 되고, 그럼 아래와 같겠죠.
(2^1) * [ (2^0 * 1) + (2^-1 * a) + (2^-2 * b) + (2^-3 * c) + ... + (2^-23 * w) ]

모든 계산식에서 가수부의 계산은 언제나 동일하게 무한급수임을 알 수 있는데, 가장 클 때가 1 + 1/2 + 1/4 + 1/8 + ... + 1/2^23 가 되어 언제나 [1, 2) 범위의 값을 가지게 됩니다. 즉, 가수부만 계산하자면 언제나 1.xxxxx 입니다.

1.xxxx 를 나타낼 때 지수부의 값은 1이므로 생략하고, 가수부는 23비트의 해상도로 [1, 2) 의 범위를 나타내게 되는데, 이를 Fixed Point와 비교하면 해석된 값이 Fixed Point 에서는 0.xxxx 이 되고 FP에서는 1.xxxx 이 되는 차이가 있으나 이는 서로의 특성으로 인한 바이어스bias일 뿐 원론적으로 전혀 차이가 없음을 알 수 있습니다. 따라서 1.xxxx 의 범위에서는 24비트 Fixed Point와 완벽하게 동일한 조건으로 데이터가 처리된다고 할 수 있습니다. 오히려 1보다 작은 값인 0.xxxx 를 나타낼 때에는 지수부가 1/2, 1/4, 1/8... 등으로 점점 작아져야 표현이 가능함을 알 수 있습니다. 각각의 경우에 [1/2, 1) [1/4, 1/2) [1/8, 1/4) 의 범위를 뜻하게 되겠지요.

이런 식으로 좀더 생각해보면 정밀도Precision 의 의미도 알게 됩니다. 24비트 Fixed Point 는 1/2^23 이 표현할 수 있는 가장 작은 수라 했습니다. 하지만 FP는 그렇지 않습니다. 앞의 지수부가 -127까지 작아질 수 있기 때문에 실제로 표현이 가능한 가장 작은 수는 다음과 같이 계산됩니다.

(2^-127) * [ (2^0 * 1) + (2^-1 * a) + (2^-2 * b) + (2^-3 * c) + ... + (2^-23 * w) ]
= (2^-127 * 1) + (2^-128 * a) + (2^-129 * b) + (2^-130 * c) + ... + (2^-140 * w)

즉, 1/2^140 이라는 작은 숫자까지 표현이 가능합니다. 따라서 정밀도가 높다고 할 수 있지요. -127보다 더 작은 지수부를 갖게 되면 다들 알고 계신 바와 같이 비정규화denormalization 이 일어나서 좀 다른 방향으로 진행되며, 이는 IEEE 표준에 따로 명시되어 있습니다.

마지막으로 FP에서 처리하는 값의 범위를 제한한 것에 대해서 생각해 보겠습니다. 2.xxxx 를 표현할 때에는 아래와 같이 되겠지요.
(2^1) * [ (2^0 * 1) + (2^-1 * a) + (2^-2 * b) + (2^-3 * c) + ... + (2^-23 * w) ]
= (2^-1 * 1) + (2^0 * a) + (2^-1 * b) + (2^-2 * c) + ... + (2^-22 * w)

보시다시피 2^-22 까지만 표현이 가능합니다. Fixed Point는 2^-23 까지 표현이 가능한데, 오히려 표현이 부정확해지고 만 셈이지요. 그래서 2.0을 포함하지 않는, 그 미만의 범위에서만 데이터를 운용할 것을 정의하고 있는 것입니다.
해당 범위를 지키기만 한다면 최소한 24비트 Fixed Point와 동일하거나, 혹은 그보다 더 좋은 정밀도Precision을 유지할 수 있음이 보장됩니다.

큐베이스/누엔도 믹서의 각 채널 페이더가 최대값을 6dB로 하고 있음도 이와 무관하지 않다 하겠습니다. 6dB는 실제 값에서는 2배를 의미하여, 해당 채널에서 출력되는 최대값이 0.xxxx 일 때, 페이더를 끝까지 올리면 실제 출력은 1.xxxx 가 되어, 2.0보다 작은 범위를 유지하게 되겠지요.

좋은 지식들 감사합니다. 수학,공학 이라면 고개를 흔들며 두손 두발 다든 몸이지만 어깨 너머로 나마 지식을 얻어감에 고마움을 느낍니다. 거리의악사 님은 이제 개발쪽에 계시는군요. 서로 연락 안한지 십수년이 흘려서 친한척 하기가 애매모호 하지만 여기서 반가운 닉네임을 들으니 기분 좋습니다.

-푼수쓰

으흠.. 저도 컴퓨터 공학 전공으로서, 처음에 좀 읽고 나도 끝에 가서 몇 마디 해야겠다 생각했는데 이거 ㅋㅋㅋㅋㅋ 모든 이야기가 다 나와 버리네요 ㅎ
아날로그에서는 표현범위(다이내믹 레인지)가 넓으면 당연히 해상도도 좋아지는데,
디지털의 float은 그게 꼭 그렇지 않다는 것에서부터 이런 얘기가 시작된게 아닐까 하고~