본문 바로가기

CS/ETC

mp3 손실 압축

반응형

무전기 플레이어를 만들면서 삽질기 10분 노트 (의식의 흐름 주의)

 

우선 mp3는 손실 압축이다.

손실 압축이기 때문에 org_wav -> mp3 -> dec_wav 로 변환했을때 dec_wav의 pcm 데이터가 압축이 되어 org_wav보다 dec_wav 파일의 크기가 당연히 작을 것이라 생각했다. ex) org_wav(1000kb) -> mp3(31kb) -> dec_wav(500kb)

막상 변환 작업을 해보니 두 파일 사이즈가 같지도 않고 유의미하게 사이즈가 다른 것도 아니었다.(대략 7kb정도 dec_wav가 컸음)

결과 값을 보니 파일 사이즈가 잘리면서 압축이 되는 건 아닌 것 같다.

바이트 숫자 값을 낮춰서 압축을 하는 건가?

이건 두 파일의 byte array를 sum해서 비교해보면 알 수 있겠네.

그러기 전에 두 파일의 크기가 다른 것부터 해결해야 테스트가 가능해지니 7kb가 붙는 이유부터 찾아보자.

 

일단 org_wav 파일의 헤더와 dec_wav 파일의 헤더를 확인해봤다.

샘플링 : 44100 같음

비트레이트 : 16 같음

채널 : 2 같음

재생시간 : 9.0, 9.04초 다름

 

머야? 재생시간이 다르네??

초당 176400바이트를 전송하니까 시간 때문에 파일 크기가 다른 건 맞는거 같은데 왜 이상한 값이 붙은거지?

chunk가 달라진 건 맞으니까 골드웨이브로 확인해보자

엥 fade_in이랑 fade_out이 들어가 있었네.

fade_in, fade_out을 잘라서 비교해보니 org_wav와 dec_wav의 파일 크기가 같다.

파일 사이즈가 다른건 fade_in이랑 fade_out이라는건 확인했고~

파일 크기를 맞췄으니 데이터 값이 어떻게 압축되는지 확인해봐야겠다.

우선 org_wav와 dev_wav의 바이트 sum을 각각 확인해보자.

 

결과부터 얘기하자면 org_wav와 dev_wav의 byte array sum이 다르다.

org_wav  : 225488255
dev_wav : 225337965

파일 사이즈는 같은데 byte sum이 다르다는건 압축하는 방식이 원본 데이터의 바이트 사이즈를 줄이는게 아닌 값을 줄이는 방식이라는거다.

오늘도 재밌는거 하나 배웠다ㅎㅎ

반응형

'CS > ETC' 카테고리의 다른 글

무전기 개념 모음  (0) 2022.11.25
APK가 만들어지는 과정  (0) 2022.05.26
Socket 내용  (0) 2022.05.26
윈도우 시스템 종료 제한  (0) 2021.11.11
IntelliJ Run Console이 지저분하게 나올 때 (Executing task....)  (0) 2021.07.22