Flash memory에서 읽혀질 수 있는 표준화된 data structure.
CFI를 통해서 system software는 장착된 flash memory의 configuration과 다양한 electrical, timing parameter, 기능들을 알 수 있다. 즉, CFI를 통해서 system은 flash device를 최적으로 interface할 수 있는 방법을 알 수 있다.
출처: ATMEL website http://www.atmel.com/dyn/products/faq_card.asp?faq_id=1745&family_id=624&family_name=Parallel%20Flash
월요일, 6월 30, 2008
일요일, 6월 29, 2008
29일 새벽 촛불집회
집회에 참가하진 못했지만 그렇다고 속편히 잠도 못자겠다. ohmynews, 한겨레, pressian, 경향의 시시각각 update되는 기사도 읽어보며, 대표적인 집회 internet 중계방송들도 동시에 보고 있다.
사진은 현재 내 컴퓨터 화면을 capture한 것.
화면우측은 ohmynews 기사화면이고 좌측은 중계방송화면들이다. 시계방향으로 우측 상단부터 ohmynews, 한겨레, 진보신당, 민중의 소리.
생각해 보니 87년 오늘이 6.29 선언일이다.
금요일, 6월 27, 2008
2008년 6월16일 영흥도 십리포해변, 소사나무 숲
지난 6월 16일 영흥도 십리포해변에 갔다가 찍은 사진을 한장을 테스트삼아 올려본다.130년된 국내 유일 소사나무 숲이라고 한다. 구불구불한 나무들이 마치 동화속에서나 나올것 같은 분위기를 만들어 낸다.
목요일, 6월 26, 2008
아버지와의 논쟁
최근 아버님 댁이 이사하시는 것을 계기로 구독신문을 중앙일보에서 경향신문으로 바꿔 보시게 했다. 중앙일보가 얼마나 악의적 편파성을 가지고 있으며 경향신문은 그다지 좌파적이지 않으면서 너무 무미건조할 정도로 공정성을 유지하고 있다고 설득하며...
그러다 이번주 월요일 아버지랑 소주한잔 할 일이 있었는데, 피하고 싶었던 현 촛불집회와 정치 경제적 상황에 대해서 논쟁이 있었다. 경향신문이 좌파적이고 선동적이란 말도 하셨고...
몇 년전부터 나는 아버지와 이런 류의 대화를 의도적으로 피하며 그냥 받아들이는 자세를 보여 왔는데, 내가 그래왔던 이유는 아버지를 결코 논리적으로 설득할 수 없고, 부모를 이기는 것은 무상한 일이며 부모님께 상처만 남길 수 있다는 것을 알기 때문이다.
오늘자 한겨례 신문에서 내 느낌을 잘 표한하는 글을 보게 되었다.
김어준의 그까이꺼 아나토미
삽화에 다음과 같이 쓰여 있다.
"지난 대선 언저리의 기억 한토막. (택시운전)기사는 육두문자를 써가며 빨갱이 정부를 성토했고, 이제 한두달 후면 새 시대가 올 것이라 확신했으며 그 시대를 이끌 지도자는 단연코 이명박 이었다. 나는 한마디 대꾸 하려다 그의 깊은 주름을 보고, 그만 두었다"
그리고 김어준은 이야기 한다. "그러나 장인(혹은 부모)을 개안시키려는 남편의 시도도 무망하다. 그건 그것대로 부모 세대의 존재양식이었기 때문에. 부모를 바꾸려는 모든 시도는, 그것이 논리적이지 않아서가 아니라 그들의 살아온 방식 자체를 부정하란 것으로 여겨지기에, 실패한다"
이 부분까지 읽는데 순간 가슴이 먹먹해 왔다.
그러다 이번주 월요일 아버지랑 소주한잔 할 일이 있었는데, 피하고 싶었던 현 촛불집회와 정치 경제적 상황에 대해서 논쟁이 있었다. 경향신문이 좌파적이고 선동적이란 말도 하셨고...
몇 년전부터 나는 아버지와 이런 류의 대화를 의도적으로 피하며 그냥 받아들이는 자세를 보여 왔는데, 내가 그래왔던 이유는 아버지를 결코 논리적으로 설득할 수 없고, 부모를 이기는 것은 무상한 일이며 부모님께 상처만 남길 수 있다는 것을 알기 때문이다.
오늘자 한겨례 신문에서 내 느낌을 잘 표한하는 글을 보게 되었다.
김어준의 그까이꺼 아나토미
삽화에 다음과 같이 쓰여 있다.
"지난 대선 언저리의 기억 한토막. (택시운전)기사는 육두문자를 써가며 빨갱이 정부를 성토했고, 이제 한두달 후면 새 시대가 올 것이라 확신했으며 그 시대를 이끌 지도자는 단연코 이명박 이었다. 나는 한마디 대꾸 하려다 그의 깊은 주름을 보고, 그만 두었다"
그리고 김어준은 이야기 한다. "그러나 장인(혹은 부모)을 개안시키려는 남편의 시도도 무망하다. 그건 그것대로 부모 세대의 존재양식이었기 때문에. 부모를 바꾸려는 모든 시도는, 그것이 논리적이지 않아서가 아니라 그들의 살아온 방식 자체를 부정하란 것으로 여겨지기에, 실패한다"
이 부분까지 읽는데 순간 가슴이 먹먹해 왔다.
수요일, 6월 25, 2008
FSRAMPERCENT
config.bib file에서 사용된다.
이 환경변수의 이름은 File System RAM PERCENT를 나타내려고 했던 것 같다.
RAM 전체크기중에서 file system (object store)에 할당되는 영역의 percentage를 설정하기 위해서 사용된다.
object store의 최소값은 32KB, 최대값은 256MB란다.
다음과 같이 4byte의 값으로 설정하는데
FSRAMPERCENT=0xXXXXXXXX
MSB쪽 byte를 byte3, LSB쪽 byte를 byte0이라고 했을 때
byte0 = 처음 2MB에서 MB당 4kbyte block의 갯수
byte1 = 두번째 2MB에서 MB당 4kbyte block의 갯수
byte2 = 세번째 2MB에서 MB당 4kbyte block의 갯수
byte3 = 나머지 memory에서 MB당 4kbyte block의 갯수
를 나타낸다.
default값이 0x80808080인데 이것은 매 MB당 512KB (4*1024*0x80)이므로 전체 RAM중 50%가 object store에 할당 되었다는 것이다.
FSRAMPERCENT에 의해 RAM상에서 object store으로 할당된 영역의 percent 계산하기
FSRAMPERCENT의 각 byte가 동일한 값을 가질 경우, 전체 RAM에서 매 1MB당 object store에 할당된 percent를 알수 있다.
예를들어 0x20202020이라면 1MB당 128KB를 할당하므로 128KB/1MB = 0.125. 전체 RAM중 12.5%가 object store에 할당 된 거다.
만일 FSRAMPERCENT의 각 byte값이 다르다면 계산이 복잡해 질수도 있겠다.
RAM상에서 object store으로 할당할 영역의 percent값으로 부터 FSRAMPERCENT 구하기
만일 12.5%를 object store에 할당하려면 FSRAMPERCENT의 각 byte를 다음과 같이 구한다.
100:12.5 = 1MB:(4KB*x)
100 * 4KB * x = 12.5 * 1MB
x = (12.5 * 1MB) / (100 * 4KB)
x = 32 = 0x20
즉 각 byte를 0x20으로 하여 FSRAMPERCENT를 0x20202020로 설정한다.
이 환경변수의 이름은 File System RAM PERCENT를 나타내려고 했던 것 같다.
RAM 전체크기중에서 file system (object store)에 할당되는 영역의 percentage를 설정하기 위해서 사용된다.
object store의 최소값은 32KB, 최대값은 256MB란다.
다음과 같이 4byte의 값으로 설정하는데
FSRAMPERCENT=0xXXXXXXXX
MSB쪽 byte를 byte3, LSB쪽 byte를 byte0이라고 했을 때
byte0 = 처음 2MB에서 MB당 4kbyte block의 갯수
byte1 = 두번째 2MB에서 MB당 4kbyte block의 갯수
byte2 = 세번째 2MB에서 MB당 4kbyte block의 갯수
byte3 = 나머지 memory에서 MB당 4kbyte block의 갯수
를 나타낸다.
default값이 0x80808080인데 이것은 매 MB당 512KB (4*1024*0x80)이므로 전체 RAM중 50%가 object store에 할당 되었다는 것이다.
FSRAMPERCENT에 의해 RAM상에서 object store으로 할당된 영역의 percent 계산하기
FSRAMPERCENT의 각 byte가 동일한 값을 가질 경우, 전체 RAM에서 매 1MB당 object store에 할당된 percent를 알수 있다.
예를들어 0x20202020이라면 1MB당 128KB를 할당하므로 128KB/1MB = 0.125. 전체 RAM중 12.5%가 object store에 할당 된 거다.
만일 FSRAMPERCENT의 각 byte값이 다르다면 계산이 복잡해 질수도 있겠다.
RAM상에서 object store으로 할당할 영역의 percent값으로 부터 FSRAMPERCENT 구하기
만일 12.5%를 object store에 할당하려면 FSRAMPERCENT의 각 byte를 다음과 같이 구한다.
100:12.5 = 1MB:(4KB*x)
100 * 4KB * x = 12.5 * 1MB
x = (12.5 * 1MB) / (100 * 4KB)
x = 32 = 0x20
즉 각 byte를 0x20으로 하여 FSRAMPERCENT를 0x20202020로 설정한다.
월요일, 6월 23, 2008
WINCEPROJ, WINCETREE, OS project, WINCEPROJ project
WINCEPROJ와 WINCETREE가 비슷하게 사용되는 것 같은데 차이가 무엇일까 조사해 봤다.
WINCEPROJ
Building powerful platforms with windows ce에서의 설명 다음과 같다.
"Project의 scope를 나타낸다. Module이 여러 project에 걸쳐서 사용될 것이라면 COMMON으로 설정되고, 현재의 project에서만 사용될 것이라면 current로 설정한다."
그러나 이것은 예전 version의 wince (아마도 3.2. 이 책은 3.2를 기준으로 쓰여졌다.)에서만 유효한 설명일 것 같다. WINCE5.0에서 WINCEPROJ는 makefile이나 sources에서 주로 directory 이름을 나타내는데 사용되는데 이것이 current로 설정되는 경우는 전혀 찾아 볼 수 없다.
사용되는 방식을 검색해 보면 다음을 알 수 있다.
여기서 _PROJECTROOT는 "WINCE500\PBWorkspaces\내 PROJECT 이름\WINCE500\내 BSP 이름"을 나타낸다. public이나 private아래의 sources, sources.cmn, makefile들에서 정의된다.
1. Public 바로 아래의 directory이름(특정 기능을 지원하는 component들과 core OS component인 common)을 나타내기 위해 사용된다. private 아래의 sources.cmn이나 sources에서도 사용되는데, 이때는 _WINCETREE의 값은 common으로 설정된다. private에 존재하는 source code로 부터 생성되는 library나 target이 실제로 존재하는 있는 위치인 common아래쪽의 directory를 나타내기 때문인 것 같다.
2. Cefilter로 intialization file들($(WINCEPROJ).reg, $(WINCEPROJ).dat, $(WINCEPROJ).bib, $(WINCEPROJ).db)들을 처리하여 intermediate directory ($(_PROJECTROOT)\cesysgen\oak\file)에 저장해 두기위해 사용된다.
3. Makeimg에게 어느 module이 resource binding이 필요한지 알리는 file인 $(WINCEPROJ).loc을 intermediate directory인 $(_PROJECTROOT)\cesysgen\oak\target에 생성한다.
4. WINCEREL=1일때 intermediate directory($(_PROJECTROOT)\cesysgen\oak\file\)에 있는 intialization file($(WINCEPROJ).*)들을 $(_FLATRELEASEDIR)로 copy하기 위해 사용되기도 한다.
즉 component를 나타내는 public아래의 directory를 나타내기 위해, initialization file의 이름을 나타내기 위해, makeimg에게 어떤 module들이 resource binding이 필요한지 알려주는 loc file의 이름을 나타내기 위해 사용된다.
또 아래의 내용을 좀더 보면 알겠지만 WINCETREE는 정의되지 않고 WINCEPROJ만 정의된 경우 WINCEPROJ project인것을 나타내기 위해서 사용된다.
WINCETREE
검색해 보면 다음을 알 수 있다.
1. Public아래의 common을 포함한 각 component directory에 있는 sources.cmn에서 그 component directory 이름을 나타낸다.
2. Makefile.def의 내용에 따르면 sources file이 include되기 전에 _COMMONPUBROOT와 __PROJROOT값을 정의한다. 이때 다음 각 경우에 따라서 다른 값으로 정의 된다.
*sysgen중 인 OS project - unsysgened input libs들을 가지고 있고 결과물이 projectroot\cesysgen에 생긴다.
OS projects during SYSGEN (which get unsysgened input libs & build into projectroot\cesysgen)
_COMMONPUBROOT=$(_PUBLICROOT)\common
__PROJROOT = $(_PROJECTROOT)\cesysgen
*compile중인 OS project - unfiltered header file들을 가지고 있고 결과물이 자신의 public tree에 생긴다.
OS projects during compile (which always get the full unfiltered headers & build into their own public tree)
_COMMONPUBROOT=$(_PUBLICROOT)\common
__PROJROOT = $(_PUBLICROOT)\$(WINCEPROJ)
*WINCEPROJ project - 이미 sysgen된 header와 lib들을 필요로 하지만 결과물은 자신의 public tree에 생긴다.
WINCEPROJ projects (which want sysgened headers & libs, but want to build into their *own* public trees)
_COMMONPUBROOT=$(_PROJECTROOT)\cesysgen
__PROJROOT = $(_PUBLICROOT)\$(WINCEPROJ)
*일반 user project - 이미 sysgen된 header와 lib들을 가지고 있고 결과물은 최종 project public tree에 생긴다.
regular user projects (which get sysgened headers & libs & build into the final project public tree)
_COMMONPUBROOT=$(_PROJECTROOT)\cesysgen
__PROJROOT = $(_PROJECTROOT)
OS project란 sources.cmn에서 WINCETREE가 정의되어 있으며 public\WINCETREE\cesysgen\makefile이 존재하는 것을 이야기 한단다.
따라서 WINCETREE 자체는 public\WINCETREE\cesysgen\makefile의 존재를 확인하기 위해서, 현재 OS project compile중 이란 것을 나타내기 위해서 사용된다.
OS project와 WINCEPROJ project
OS project compile중인가 아니면 WINCEPROJ project중인가에 따라서 결국 어디에 dependency를 가지며 어디로 결과물이 생긴다는 것이 정의된다.
WINCEPROJ project - sysgen중이 아니고 WINCETREE가 정의되어 있지 않으면서 WINCEPROJ만 정의된 것으로 이때는 sysgen의 결과물에 dependecy를 갖고 자신의 public directory에 결과물이 생성된다.
OS project - WINCETREE가 정의 된 것으로 sysgen되기 전의 unfiltered header file에 dependency를 갖고 결과물은 자신의 public directory에 생성된다. (sysgen은 OS project에 대해서 이루어 진다는 것은 당연한 것라 하겠다.)
다 써놓고 보니 내가 봐도 무슨소린지 잘 모르겠다는 생각도 든다.
역시 Windows CE에서 제일 어려운것은 BUILD다.
WINCEPROJ
Building powerful platforms with windows ce에서의 설명 다음과 같다.
"Project의 scope를 나타낸다. Module이 여러 project에 걸쳐서 사용될 것이라면 COMMON으로 설정되고, 현재의 project에서만 사용될 것이라면 current로 설정한다."
그러나 이것은 예전 version의 wince (아마도 3.2. 이 책은 3.2를 기준으로 쓰여졌다.)에서만 유효한 설명일 것 같다. WINCE5.0에서 WINCEPROJ는 makefile이나 sources에서 주로 directory 이름을 나타내는데 사용되는데 이것이 current로 설정되는 경우는 전혀 찾아 볼 수 없다.
사용되는 방식을 검색해 보면 다음을 알 수 있다.
여기서 _PROJECTROOT는 "WINCE500\PBWorkspaces\내 PROJECT 이름\WINCE500\내 BSP 이름"을 나타낸다. public이나 private아래의 sources, sources.cmn, makefile들에서 정의된다.
1. Public 바로 아래의 directory이름(특정 기능을 지원하는 component들과 core OS component인 common)을 나타내기 위해 사용된다. private 아래의 sources.cmn이나 sources에서도 사용되는데, 이때는 _WINCETREE의 값은 common으로 설정된다. private에 존재하는 source code로 부터 생성되는 library나 target이 실제로 존재하는 있는 위치인 common아래쪽의 directory를 나타내기 때문인 것 같다.
2. Cefilter로 intialization file들($(WINCEPROJ).reg, $(WINCEPROJ).dat, $(WINCEPROJ).bib, $(WINCEPROJ).db)들을 처리하여 intermediate directory ($(_PROJECTROOT)\cesysgen\oak\file)에 저장해 두기위해 사용된다.
3. Makeimg에게 어느 module이 resource binding이 필요한지 알리는 file인 $(WINCEPROJ).loc을 intermediate directory인 $(_PROJECTROOT)\cesysgen\oak\target에 생성한다.
4. WINCEREL=1일때 intermediate directory($(_PROJECTROOT)\cesysgen\oak\file\)에 있는 intialization file($(WINCEPROJ).*)들을 $(_FLATRELEASEDIR)로 copy하기 위해 사용되기도 한다.
즉 component를 나타내는 public아래의 directory를 나타내기 위해, initialization file의 이름을 나타내기 위해, makeimg에게 어떤 module들이 resource binding이 필요한지 알려주는 loc file의 이름을 나타내기 위해 사용된다.
또 아래의 내용을 좀더 보면 알겠지만 WINCETREE는 정의되지 않고 WINCEPROJ만 정의된 경우 WINCEPROJ project인것을 나타내기 위해서 사용된다.
WINCETREE
검색해 보면 다음을 알 수 있다.
1. Public아래의 common을 포함한 각 component directory에 있는 sources.cmn에서 그 component directory 이름을 나타낸다.
2. Makefile.def의 내용에 따르면 sources file이 include되기 전에 _COMMONPUBROOT와 __PROJROOT값을 정의한다. 이때 다음 각 경우에 따라서 다른 값으로 정의 된다.
*sysgen중 인 OS project - unsysgened input libs들을 가지고 있고 결과물이 projectroot\cesysgen에 생긴다.
OS projects during SYSGEN (which get unsysgened input libs & build into projectroot\cesysgen)
_COMMONPUBROOT=$(_PUBLICROOT)\common
__PROJROOT = $(_PROJECTROOT)\cesysgen
*compile중인 OS project - unfiltered header file들을 가지고 있고 결과물이 자신의 public tree에 생긴다.
OS projects during compile (which always get the full unfiltered headers & build into their own public tree)
_COMMONPUBROOT=$(_PUBLICROOT)\common
__PROJROOT = $(_PUBLICROOT)\$(WINCEPROJ)
*WINCEPROJ project - 이미 sysgen된 header와 lib들을 필요로 하지만 결과물은 자신의 public tree에 생긴다.
WINCEPROJ projects (which want sysgened headers & libs, but want to build into their *own* public trees)
_COMMONPUBROOT=$(_PROJECTROOT)\cesysgen
__PROJROOT = $(_PUBLICROOT)\$(WINCEPROJ)
*일반 user project - 이미 sysgen된 header와 lib들을 가지고 있고 결과물은 최종 project public tree에 생긴다.
regular user projects (which get sysgened headers & libs & build into the final project public tree)
_COMMONPUBROOT=$(_PROJECTROOT)\cesysgen
__PROJROOT = $(_PROJECTROOT)
OS project란 sources.cmn에서 WINCETREE가 정의되어 있으며 public\WINCETREE\cesysgen\makefile이 존재하는 것을 이야기 한단다.
따라서 WINCETREE 자체는 public\WINCETREE\cesysgen\makefile의 존재를 확인하기 위해서, 현재 OS project compile중 이란 것을 나타내기 위해서 사용된다.
OS project와 WINCEPROJ project
OS project compile중인가 아니면 WINCEPROJ project중인가에 따라서 결국 어디에 dependency를 가지며 어디로 결과물이 생긴다는 것이 정의된다.
WINCEPROJ project - sysgen중이 아니고 WINCETREE가 정의되어 있지 않으면서 WINCEPROJ만 정의된 것으로 이때는 sysgen의 결과물에 dependecy를 갖고 자신의 public directory에 결과물이 생성된다.
OS project - WINCETREE가 정의 된 것으로 sysgen되기 전의 unfiltered header file에 dependency를 갖고 결과물은 자신의 public directory에 생성된다. (sysgen은 OS project에 대해서 이루어 진다는 것은 당연한 것라 하겠다.)
다 써놓고 보니 내가 봐도 무슨소린지 잘 모르겠다는 생각도 든다.
역시 Windows CE에서 제일 어려운것은 BUILD다.
금요일, 6월 20, 2008
WINCETARGETFILE0와 WINCETARGETFILES
WINCETARGETFILE0
sources file내에서 이 macro가 정의되어 있다면 현재 sources와 source code들이 있는 directory내의 makefile.inc가 (optional한 file로써 custom build rule이 필요할 때 추가해 준다) central makefile의 흐름상에 추가되어 현재 directory의 build를 위한 custom rule를 정의한다.
이것은 한마디로 해당 directory 내의 source code들을 build하기 전에 custom rule로써 처리 해 줘야 할 target을 정의해 준다.
central makefile인 makefile.def의 All target의 dependency list의 제일 앞에 추가 된다. 즉 다른 무엇보다 제일 먼저 custom rule로 처리되는 녀석을 나타낼때 쓴다.
WINCETARGETFILES
이건 WINCETARGETFILE0와 같은 기능을 하는데 단지 makefile.def의 ALL target의 dependency list의 제일 뒷쪽에 추가된다는 것이 다르다. 즉 이것은 다른 모든것들이 처리된 다음에 제일 마지막에 custom rule로 처리되야 하는 녀석을 나타낼때 쓴다.
이것들은 흔히 어떤 file들을 intermediate directory에 때로는 이름을 바꿔서 copy하는 경우에 사용된다.
예를 들면, sources file에서 다음과 같이 정의되고
TARGETNAME=waveui
WINCETARGETFILES=$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\waveapi.res
makefile.inc에서 다음과 같이 정의되어 있다면
$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\waveapi.res:$(_OBJDIR)\$(TARGETNAME).res
copy $? $@
이게 무슨 뜻인가?
단지 $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\waveapi.res을 $(_OBJDIR)\waveui.res로 이름을 바꿔서 copy하라는 소리다.
sources file내에서 이 macro가 정의되어 있다면 현재 sources와 source code들이 있는 directory내의 makefile.inc가 (optional한 file로써 custom build rule이 필요할 때 추가해 준다) central makefile의 흐름상에 추가되어 현재 directory의 build를 위한 custom rule를 정의한다.
이것은 한마디로 해당 directory 내의 source code들을 build하기 전에 custom rule로써 처리 해 줘야 할 target을 정의해 준다.
central makefile인 makefile.def의 All target의 dependency list의 제일 앞에 추가 된다. 즉 다른 무엇보다 제일 먼저 custom rule로 처리되는 녀석을 나타낼때 쓴다.
WINCETARGETFILES
이건 WINCETARGETFILE0와 같은 기능을 하는데 단지 makefile.def의 ALL target의 dependency list의 제일 뒷쪽에 추가된다는 것이 다르다. 즉 이것은 다른 모든것들이 처리된 다음에 제일 마지막에 custom rule로 처리되야 하는 녀석을 나타낼때 쓴다.
이것들은 흔히 어떤 file들을 intermediate directory에 때로는 이름을 바꿔서 copy하는 경우에 사용된다.
예를 들면, sources file에서 다음과 같이 정의되고
TARGETNAME=waveui
WINCETARGETFILES=$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\waveapi.res
makefile.inc에서 다음과 같이 정의되어 있다면
$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\waveapi.res:$(_OBJDIR)\$(TARGETNAME).res
copy $? $@
이게 무슨 뜻인가?
단지 $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\waveapi.res을 $(_OBJDIR)\waveui.res로 이름을 바꿔서 copy하라는 소리다.
화요일, 6월 03, 2008
G.711과 PCM
G.711은 흔히 말하는 PCM(pulse code modulation)과 같은 것 입니다. Analog signal을 digital화 하기 위해 sampling하는 방법을 이야기 합니다. 그중 전화통신 응용에서는 8bit resolution에 64kbps의 bit rate을 사용하는데, 이것은 8khz(64*1024/8) sampling rate을 갖고, 각 sample은 8bit로 표현된다는 소리입니다.
G.711이 그냥 PCM과 다른 점은 이렇게 전화 통신에서는 8bit resolution, 8khz sampling rate으로 표현하므로 발생하는 음질의 감소를 보정하기 위해서 각 sampling 값들을 특정 값들로 대치하는 방법을 사용하고 이때 사용되는 sampling 변환 table에 따라서 두가지 방식이 사용된다고 합니다. Mu-law standard는 북미와 일본에서 사용되고, A-law standard는 유럽국가들에서 사용됩니다.
Audio CD 이나 DVD의 경우 linear PCM이 사용됩니다.
Audio CD의 경우 2 channel, 16bit resolution, 44.1khz sampling rate PCM format입니다.
DVD 영화의 audio는 dolby digital이나 DTS에서 multi-channel surround을 지원하므로 8 channel에 (7.1 channel surround) 8, 16, 20, 24bit resolution, 48, 96khz sampling rate 까지 지원합니다.
DVD-Audio의 경우 24bit resolution에 192khz sampling rate를 지원합니다.
G.711이란 것은 telephone audio을 PCM 64kbps, 1 channel에서 encoding하기 위해, 그리고 이에따라 감소된 음질에 대응하기 위해서 sample 변환 table을 사용하도록 해서, ITU-T 국제표준으로 채택하면서 붙인 이름이라고 보면 될 겁니다.
G.711이 그냥 PCM과 다른 점은 이렇게 전화 통신에서는 8bit resolution, 8khz sampling rate으로 표현하므로 발생하는 음질의 감소를 보정하기 위해서 각 sampling 값들을 특정 값들로 대치하는 방법을 사용하고 이때 사용되는 sampling 변환 table에 따라서 두가지 방식이 사용된다고 합니다. Mu-law standard는 북미와 일본에서 사용되고, A-law standard는 유럽국가들에서 사용됩니다.
Audio CD 이나 DVD의 경우 linear PCM이 사용됩니다.
Audio CD의 경우 2 channel, 16bit resolution, 44.1khz sampling rate PCM format입니다.
DVD 영화의 audio는 dolby digital이나 DTS에서 multi-channel surround을 지원하므로 8 channel에 (7.1 channel surround) 8, 16, 20, 24bit resolution, 48, 96khz sampling rate 까지 지원합니다.
DVD-Audio의 경우 24bit resolution에 192khz sampling rate를 지원합니다.
G.711이란 것은 telephone audio을 PCM 64kbps, 1 channel에서 encoding하기 위해, 그리고 이에따라 감소된 음질에 대응하기 위해서 sample 변환 table을 사용하도록 해서, ITU-T 국제표준으로 채택하면서 붙인 이름이라고 보면 될 겁니다.
피드 구독하기:
글 (Atom)
