RMS 목표값과 재측정값이 다를 때 확인할 것

처음에 실패한 측정 항목을 지우지 않았다

초기 검증 보고서는 RMS 재측정 항목을 실패로 기록했다. 요청값과 출력의 독립 계산값이 기대한 방식으로 맞지 않았기 때문이다. 파일이 만들어졌고 프로그램이 정상 종료했다는 사실만으로 그 항목을 통과시킨 것은 아니었다.

보관된 REAPER 설치 도움말과 Rust의 배치 설정 코드를 대조했다. 도움말은 정규화 모드와 목표값의 인자를 설명하고, 코드는 rms 선택을 해당 엔진 모드에 연결한다. 옵션을 전달하는 구조는 여기서 읽을 수 있다. 그 옵션으로 어떤 출력이 나오는지는 결과 파일을 따로 확인해야 한다.

재측정값이 어느 계산에서 나왔는지 읽었다

대조에 사용한 코드는 출력 WAV의 PCM 샘플을 읽어 제곱의 평균을 구하고 제곱근을 취한 뒤 dBFS로 바꾼다. 아래 식은 그 비교에서 사용한 비무음·단일 채널 PCM16 신호의 전체 파일 산술 계산을 설명한 것이다. 모든 RMS 계측기의 내부 구현을 나타내는 식으로 소개하지 않는다.

과거 보고서의 native_rms_dbfs는 검증 코드가 원래 엔진의 출력 WAV를 읽어 계산한 값이다. REAPER 내부 계측기를 직접 읽은 값이 아니다. 필드 이름만 보면 측정한 주체를 오해할 수 있어, 그 값을 만드는 코드까지 따라갔다.

여기서는 요청한 정규화 목표와 출력 전체의 산술 측정값을 각각 적는다. 약 -17.79153 dBFS라는 표시는 보고서의 원래 값을 반올림한 것이며 새로 측정한 결과가 아니다.

rms = sqrt(sum(sample * sample) / sample_count)
dBFS = 20 * log10(rms / 32768)

보정하기 전에 원래 엔진의 출력을 비교했다

과거의 직접 대조는 같은 합성 정현파를 원래 REAPER 배치 변환기에 넣고, 그 출력 PCM을 CLI를 거쳐 만든 출력과 비교했다. 선택한 4초 신호에서 두 샘플 배열이 같았다는 결과가 남아 있다. 이 표본에서는 CLI를 거치면서 생긴 PCM 차이를 찾지 못했다는 근거다.

이 결과로 REAPER의 내부 RMS 계산식을 알아냈다고 말할 수는 없다. 대조 코드에는 관찰값으로부터 추가 측정 시간을 역산한 항목도 있지만, 그것은 추정 계산이다. 엔진이 실제로 그 길이의 구간을 사용한다는 증거로 바꾸지 않았다. 요청과 산술 측정의 차이를 임의의 상수로 보정하지 않은 이유이기도 하다.

최종 검증은 CLI 출력과 직접 실행한 엔진 출력의 PCM이 같은지 확인하고, 측정 방식의 차이를 안내하는지도 검사한다. 통과 기록의 뜻은 그 항목들에 한정된다. 전체 파일 산술 RMS가 정확히 -18 dBFS가 됐다는 뜻은 아니다. 그 값이 꼭 필요한 작업이라면 요구 조건과 계측 기준을 별도로 정해 검증해야 한다.

결과를 넘길 때 목표와 계측 조건을 같이 적는다

독자가 비슷한 변환을 확인한다면 요청한 모드·목표값과 결과 파일의 측정값을 나눠 적을 수 있다. 측정에는 사용한 도구나 계산식, 읽은 구간과 채널·샘플 형식을 함께 남긴다. 값이 다르면 같은 입력과 조건으로 원래 엔진을 직접 사용한 결과도 대조할 수 있다.

원래 엔진과 같은 PCM을 얻었는지 확인하는 호환성 검사와, 특정 계측기로 목표값을 얻었는지 확인하는 검사는 따로 둔다. 입력·옵션·출력 경로가 같아도 실제 사용처의 음량 조건은 더 확인해야 할 수 있다. 어느 검사를 통과했는지 결과에 명시해야 한다.

이번에는 기존 코드·설치 도움말의 보관본·초기 실패·직접 대조·최종 검증 기록을 읽었다. REAPER와 CLI를 새로 실행하거나 음원을 생성·변환하지 않았고, 실제 음성·음악을 청취하지도 않았다. 이 합성 신호의 대조를 모든 오디오의 음질과 호환성으로 넓히지 않는다.