공식 설치 메뉴얼: https://www.tensorflow.org/install/install_windows


TensorFlow 설치 전에 먼저 깔아야 하는 것들(Requirements)

- CUDA Toolkit 8.0

- cuDNN v6.1


주의할 점은 위 requirement들을 최신 버전으로 깔면 TensorFlow가 지원을 안함 ㅡㅡ;;

현재 CUDA 9.1과 cuDNN 7이 최신이라 홈페이지 메인에 떡하니 있는데, 좋다고 넙죽 받아서 설치하면 당연 안되고

꽁꽁 숨어있는 Legacy 다운로드 메뉴로 들어가서 굳이 구버전을 깔아야 함


CUDA Toolkit은 크기가 좀 커서 그렇지(1.5GB) 그냥 깔면 되고

cuDNN은 받아서 압축 풀면 dll이 튀어나오는데, 적절히 원하는 폴더에 넣고 환경 변수에 해당 경로를 박아야 함

예를 들어 C:\Program Files\cudnn 폴더 만들고 그 안에 cudnn64_5.dll를 넣었으면 그 경로를 %PATH%에 박고 재부팅ㄱ





TensorFlow가 잘 깔렸는지 확인하는 파이썬 스크립트:

https://gist.github.com/mrry/ee5dbcfdd045fa48a27d56664411d41c#file-tensorflow_self_check-py

[Sampling]

이 세상의 소리(Sound)라는 것은 아날로그이기에 Linear 하다.

그런데 컴퓨터는 디지털이므로 이 Linear한 소리를 Discrete 한 데이터로 변환해야 한다.

 

아날로그는 거의 무한대의 해상도를 가지므로 이것을 그대로 디지털로 표현하는 건 불가능하다.

따라서 그 일부분만 채취(샘플링)하여 최대한 원본과 유사한 디지털 데이터를 만들어야 한다.

이러한 과정 또는 행위를 샘플링이라 한다.

 

용어가 몇 개 있다:

(1) 샘플링 레이트(Sampling Rate) : 1초에 몇 개의 샘플을 추출할 것인지

(2) Bit Depth : 한 개의 샘플이 얼마만큼의 정확도/단계를 가지는지

 

샘플링 레이트가 높을 수록 아날로그와 유사한 모양의 데이터를 얻을 수 있다.

아래 그림은 샘플링 레이트에 따른 디지털 데이터의 모양을 나타낸다.

잘게 쪼갤 수록 아날로그의 것과 같이 부드러운 곡선이 되는 것(=원본에 가까움)을 확인할 수 있다.

 

더불어서 각 샘플(sample)이 표현할 수 있는 값의 범위를 sample size 라고 한다.

하나의 샘플이 0부터 1까지의 값을 표현할 것인데 이를 얼마나 정밀하게 표현할 것인가...

예를 들어 샘플 사이즈가 3 bit라면 8단계로 표현 가능할 것이다. (0.0, 0.125, 0.25, 0.375, ...)

(출처: http://www.morphfx.co.uk/music/edu-sampling.htm)

 

따라서 아날로그를 디지털로 샘플링 시 필요한 용량은 Sample Rate와 Sample Size의 곱이다.

 

예를 들어보자. 우리가 일반적으로 구입할 수 있는 음반 CD의 스펙은 44,100 Hz, 16-bit 이다.

이는 1초에 44100개의 샘플을 추출하고, 각 샘플의 크기는 16 bit 라는 것이다.

따라서 둘을 곱하면 705,600 bit가 1초를 표현하는 데 사용된다. (88,200 byte = 86.13 KB)

이론상 4분짜리 곡은 20.15 MB가 필요할 것이다. 실제로 WAV, PCM 등의 무손실이면 이 용량이 나온다.

 

 

[나이퀴스트 샘플링 이론(Nyquist–Shannon sampling theorem)]

왜 대부분의 MP3 파일, 혹은 하드웨어들이 44,100 hz 스펙을 가지고 있는지 대충 납득할 수 있다.

 

이 이론의 결론을 요약하면 다음과 같다:

A sufficient sample-rate is therefore 2B samples/second, or anything larger. 

충분한 샘플링 레이트는 대역폭의 두 배, 혹은 그 이상이다.

 

더보기

우선 앨리어싱(Aliasing)이라는 개념이 있다.

원본을 샘플링하여 새로이 구성된 데이터가 원본과 다를 때 발생하는 왜곡이나 아티팩트를 의미한다.

 

샘플링 레이트가 충분히 높지 않다면 샘플된 데이터는 원본 데이터를 충분히 표현하지 못한다. 당연한 말이다.

아래 그림은 벽돌 벽(원본)을 사진(샘플링)으로 촬영한 사진이다.

 

충분히 큰 해상도로 촬영하여, 벽돌의 규칙적인 모양을 잘 표현한 사진

  

낮은 해상도로 촬영하였기에 벽돌의 연속적인 패턴을 제대로 표현하지 못하는 모습

 

이 건물은 벽돌이 연속성을 가지고 배치되어 있다.

그런데 낮은 해상도로 사진을 찍을 경우 벽돌의 연속성을 제대로 표현하지 못하고 원본과 다른 왜곡된 모습을 표현하게 된다. 마치 시멘트가 좀 더 많이 발려진 것 같이 보인다.

 

이유는 갈색 벽돌 부분과 흰색 시멘트라는 두 요소를 조화롭게 샘플링해야 하는데

샘플링 비율이 한 쪽에 치우치게 되면 원래의 모양이 왜곡된 것처럼 보이는 것이다.

 

그런데 무조건 이 문제가 생기는 것은 아니고...

정말 재수가 좋아서 원본의 특징점을 잘 샘플링 할 경우... 딱히 문제가 없을 수도 있다.

혹은 눈속임으로 샘플들 사이를 비벼버리는 테크닉도 있다. (anti-aliasing)

 

시그널 프로세싱은 이러한 아다리를 지향한다고 할 수 있다.

어떻게 하면 최대한 적은 샘플링으로 원본의 특징을 그대로 살릴 수 있을지...

이와 관련하여 나이퀴스트는 Aliasing이 발생하지 않는 샘플링 레이트를 대역폭의 2배라고 제시한 것이다.

 

관련해서 자세한 내용은 관련 논문 참고:

http://medialab.sjtu.edu.cn/teaching/DIP/Projects/chapter_bas/ShannonTheoremTutorial.pdf

 

사람이 소리로 들을 수 있는 가청 주파수의 범위는 20~20,000 Hz 으로 알려져 있다. (나는 16,000 까지밖에 안들리던데...)

즉 데이터의 대역폭이 20 KHz라는 것인데, 이를 왜곡(Aliasing 등) 없이 샘플링 하려면

대역폭의 2배인 40 KHz 샘플링 레이트 이상으로 샘플링 해야한다는 이론이다.

 

하지만 이론상의 최소 요구가 2배라는 것이고, real-world에서는 8배 정도가 안전하다는 얘기를 엔지니어들이 종종 한다.

그렇기 때문에 192 kHz 까지 사용하는 Hi-Fi 업계가 존재하는 것으로 보인다.

 

현재는 44,100Hz와 48,000Hz가 범용적으로 가장 많이 사용되고 있다.

44,100hz : 25FPS PAL, 30FPS NTSC

48,000hz : 29.97FPS NTSC

 

 

 

[Sources]

https://en.wikipedia.org/wiki/Sampling_(signal_processing)

https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

https://en.wikipedia.org/wiki/Aliasing

최근 서버가 자꾸 shutdown 되는 상황이 발생하여 로그를 살펴보았습니다.

사용중인 운영체제는 CentOS 7 64비트입니다.


cat /var/log/messages | grep 'System is powering down.'


불규칙적으로 서버가 꺼지는 현상이 발생했는데, 신기하게도 비정상 종료가 아니라 정상 종료(Shutdown)였습니다.

파워나 보드 등의 부품 문제로 인한 갑작스런 전원 종료는 아닌 것입니다.


누군가 리눅스를 일부러 끄고 있다는 생각이 들어 해킹을 의심했으나, 로그에서 다음과 같은 부분을 발견했습니다.


Jan 10 22:23:31 localhost systemd-logind: Power key pressed.

Jan 10 22:23:31 localhost systemd-logind: Powering Off...


놀랍게도 전원 버튼이 눌려 시스템이 꺼지고 있었습니다. 그런데 주변에 물어봐도 아무도 누른 사람이 없습니다.

이 상태로 한 2주 지나니까 이젠 시스템을 켜면 3초 안에 자동으로 꺼집니다. 그리고 다시 알아서 켜지고, 반복됩니다.


전원 버튼 고장으로 결론을 내릴 수밖에 없는 상황입니다.


그런데 이미 제 TS140은 구입 후 1년이 경과하여 무상 RMA 불가하고, 해외 수입 제품이므로 국내 유상 A/S도 불가능합니다.

TS140 Front Bezel을 구입하여 교체하면 되지만 일단 당장 서버를 살리고 봐야 하니 나중으로 미룹니다.



메인보드의 우측하단에 전면부 패널과의 연결 케이블이 있습니다.

이 케이블을 Plug-Out 하였더니 시스템이 꺼졌다 켜졌다 하는 일은 사라졌습니다.

아무래도 전원 버튼 고장이 확실해 보입니다.



그런데 전원 버튼 연결선을 뽑아버렸으니 컴퓨터를 켤 방법이 없어졌습니다.

전원 시그널 핀 2개를 드라이버로 쇼트 내면 켜지긴 합니다만, 이걸 매 번 옆커버 따서 할 수는 없는 일입니다.



그래서 꼼수를 써 봅니다. 부팅 시 F1을 눌러 CMOS를 들어가면 파워 설정이 있습니다.

이 중에서 '전원 케이블이 연결되면 자동으로 시스템이 켜지도록' 하는 옵션이 존재합니다.

이 옵션을 ON으로 하여, 전원선을 뽑았다 꽂으면 시스템이 켜지도록 하였습니다.



전원을 끄는 것은 문제가 없습니다. 리눅스에서 shutdown 명령어로 종료하도록 합니다.



일단 이렇게 조치하여, Front Bezel이 도착할 때까지는 운영이 가능하겠습니다.

맥(Mac OS X)에 Java 8 (JRE, JDK, jdk1.8) 설치하는 방법입니다.


기존에 Legacy Java 6(2015-001)을 설치했더라도 상관 없습니다.

두 Java는 서로 영향 없이 맥에 공존하게 됩니다.




1. 다운로드 및 설치

우선 말씀드릴 점은, 여러가지 사유로 인해 JRE보다 JDK를 설치하는게 일이 간단합니다.


어차피 Java 8 설치하시는 분들은 Eclipse 혹은 관련 개발을 위함이라 생각되기 때문에

JRE는 건너뛰고 JDK를 설치하도록 합니다. (JDK는 JRE를 포함하고 있습니다.)


http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html




2. 터미널 명령어 java를 jre1.8로 연결

현재 상태에서 터미널에 java -version 을 치면 두 가지 케이스로 나눠지는데

  첫째는, 아무런 Java를 설치하지 않아 설치 창이 튀어나오는 경우

  둘째는, java 1.6.0이 설치되어 있다고 나오는 경우


어쨌거나 두 케이스 다 Java 8과는 연결되지 않기 때문에 새로이 연결하도록 합시다.


본 작업은 /usr/bin 디렉토리 내의 파일을 변경하므로, rootless 기능을 꺼야 가능합니다.

끄는 방법은 구글링을 하시기 바랍니다.


ls /Library/Java/JavaVirtualMachines


위 명령어로 현재 설치된 jdk1.8의 폴더명을 알아냅니다.


sudo rm /usr/bin/java

sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/bin/java /usr/bin/java




3. 끝

연결이 끝났습니다.

java -version 을 쳐서 Java 1.8.0 버전을 확인하고 기분 좋아하도록 합니다.

StartSSL에서 인증서 발급 받는 방법은 해당 글에서 확인하시기 바랍니다.


- 본 글은 RedHat 계열 기준으로 작성되었습니다. Debian, Ubuntu는 내용이 다릅니다.

- 본 글은 CentOS 7 기준으로 작성되었으며, 아파치는 yum 기반 설치를 가정합니다.



1. 아파치 SSL 모듈 설치


yum -y install mod_ssl



2. 서버에 인증서 저장


mkdir /etc/httpd/conf/ssl


# /etc/httpd/conf/ssl 경로에 아래의 인증서 파일들을 저장합니다.

# 경로는 바뀌어도 상관 없습니다. 아래 4번 항목에서 해당 경로를 수정해 주면 됩니다.


# 넣어야 하는 인증서 관련 파일:

#     acu.pe.kr.crt (도메인 인증서) (StartSSL에서 제공하는 zip 파일에 동봉)

#     private.key (비밀키)


# 인증서 파일들에 대한 권한 설정

chown -R root.root /etc/httpd/conf/ssl

chmod -R 644 /etc/httpd/conf/ssl



3. 아파치 설정 파일(httpd.conf)에 SSL 모듈 로드, 옵션 파일 추가


vi /etc/httpd/conf/httpd.conf


# 아래 내용 추가 (빨간 부분을 서버에 맞게 수정)

LoadModule ssl_module modules/mod_ssl.so

Listen 443

<VirtualHost *:443>

    ServerName acu.pe.kr

    ServerAlias www.acu.pe.kr

    DocumentRoot /var/www/html

    SSLEngine on

    SSLCertificateFile /etc/httpd/conf/ssl/acu.pe.kr.crt

    SSLCertificateKeyFile /etc/httpd/conf/ssl/private.key

</VirtualHost>



4. 아파치 재시작


systemctl restart httpd


# 아파치 실행 시 비밀키(private.key)의 pass phrase를 물어봅니다.

# 비밀키를 생성할 때 입력했던 비밀번호를 입력하시면 됩니다.


# 아파치를 실행할 때마다 pass pharase를 입력하기가 귀찮으시면

# 인증서에 아예 비밀번호를 입력시킬 수 있습니다.

openssl rsa -in /etc/httpd/conf/ssl/private.key -out /etc/httpd/conf/ssl/private.key


# 단, 이렇게 되면 이제부터 개인키 파일이 외부로 노출되어서는 절대 안됩니다.

# 또한 작업하기 전의 원본 파일을 별도로 백업해 두시기 바랍니다. (갱신 시 필요)



5. SSL 적용 테스트


테스트 사이트: https://www.digicert.com/help/



*. 에러 발생 시


이런 메시지가 출력되면 실행에 실패한 것임:

Job for httpd.service failed because the control process exited with error code.


왜 실행이 실패했는 지 로그 확인:

systemctl status -l httpd


문제: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443

이유: 다른 프로세스가 443 포트를 이미 사용중이므로, 해당 프로세스를 종료해야 함

해결: netstat -tunap | grep 443 명령어로 어떤 프로세스가 사용중인지 확인 후 종료

해결: 해결이 안되면 아파치 설정에 Listen 443이 중복 선언된 것, 따라서 주석 처리


문제: 홈페이지 접속 시 신뢰할 수 없는 인증서 메시지가 출력됨

증상: 서버의 인증서(crt)와 브라우저에 나타난 인증서의 지문(fingerprint)이 같지 않음

증상: Common Name(CA)에 이상한 랜덤 숫자가 표시됨

이유: 인증서가 아파치에 제대로 로드되지 않아 엉뚱한 인증서를 클라이언트에 제공함

해결: httpd.conf의 VirtualHost 443이 도메인을 잘 낚아채도록 수정


StartSSL 사이트에서 무료로 1년 사용 가능한 SSL 인증서를 발급받을 수 있습니다.



1. 사이트 접속 (https://www.startssl.com) 및 회원 가입


오른쪽 상단의 Sign-up을 눌러 회원 가입을 진행합니다.






StartSSL 사이트는 흔히 알던 아이디-비밀번호 방식이 아닌 이메일-인증서 방식입니다.


이메일을 입력하고 인증번호 단계를 거치면 브라우저에 인증서를 발급하여 저장해 줍니다.

인증서가 곧 ID와 같은 역할을 해 줍니다.



인증번호 입력 과정이 끝나면 브라우저에 인증서가 발급됩니다.

(주의: 포멧 등의 사유로 인증서가 브라우저에서 삭제되지 않도록 주의 바랍니다.)






Login Now 버튼을 눌러 로그인에 진입합니다.







2. 로그인


브라우저의 인증서를 통해 1차로 인증이 완료되면 OTP 단계에 진입합니다.


인증서를 선택하고 로그인을 시도하면, 이메일로 일회용 비밀번호가 발급됩니다.

이메일로 전송된 일회용 비밀번호를 입력하여 로그인합니다.







3. 도메인 인증 (소유권 주장)


SSL 인증서를 발급받기 전에, 먼저 해야 하는 단계가 있습니다.

인증서를 발급받고자 하는 도메인에 대한 소유권을 인증해야 해야 합니다.


도메인의 소유자만 해당 도메인에 대해 인증서를 발급할 수 있습니다.

제3자가 내 도메인 이름으로 인증서를 발급하고, 피싱 페이지를 만들 수도 있기 때문이죠.


Validations Wizard 버튼을 눌러 해당 메뉴로 진입합니다.






맨 위의 '도메인 인증'을 선택하고 진행합니다.







인증받고자 하는 도메인을 입력합니다.






해당 도메인을 소유하고 있는지를 도메인 메일 인증을 통해 처리합니다.


부득이하게 도메인 메일이 없거나, webmaster같은 이메일 계정이 없어서 인증이 어렵다면

또 다른 인증 방식인 website control validation을 통해 인증 가능합니다.


(주어지는 html 파일을 웹사이트 루트에 업로드하여 이를 검사하는 방식입니다.)







도메인에 대한 인증(소유권)이 완료되었습니다.

Order SSL 버튼을 통해 인증서 발급 단계로 진입합니다.







4. 인증서 발급


호스트네임을 입력합니다. 무료 인증서는 5개까지 입력 가능합니다.

첫 번째 줄에 입력된 호스트네임이 인증서의 common name이 됩니다.


일반적으로 www를 포함한 도메인과 포함하지 않은 도메인을 입력합니다. (총 2개)







SSL/TLS는 공개키 암호 방식을 사용하기 때문에 공개키비밀키를 생성해야 합니다.

더불어서 인증서에 추가 정보(회사명, 기관명, 회사 주소, 이메일 등)를 입력해야 합니다.


공개키와 추가 정보를 합친 파일을 Certificate Signing Request(CSR) 이라고 합니다.

이 파일은 우리가 손으로 직접 만들 수는 없고 Tool을 사용하여 생성해야 합니다.


비밀키를 먼저 만들고, 비밀키를 사용하여 공개키를 생성하게 됩니다.

일반적으로 비밀키는 랜덤한 값으로 만들기 때문에, 이 역시 Tool이 알아서 해 줄 것입니다.


리눅스에서는 빨간 글씨로 제공된 openssl 명령어를 통해,

윈도우 상에서는 제공되는 StartComTool.exe 프로그램을 통해 생성 가능합니다.


위 Tool을 사용한다면 비밀키(key) 파일과 공개키+추가 정보(csr) 파일이 생성됩니다.

비밀키 파일은 서버 내의 안전한 곳에 잘 보관하시고 유출되지 않도록 해야 합니다.


생성된 CSR 파일의 내용을 복사하여 홈페이지에 입력하고 다음 단계로 진행합니다.







인증서 발급이 성공적으로 완료되었습니다.







5. 인증서 다운로드


Tool Box 메뉴 최상단의 인증서 목록(Certificate List) 메뉴로 진입합니다.







목록에 2개의 인증서가 보일 것입니다 (Products 항목으로 구분하세요)

- 하나는 방금 만든 SSL 인증서입니다.

- 하나는 StartSSL 사이트에 로그인 할 때 사용하는 Client 인증서입니다.


SSL 인증서 우측의 Retrieve 버튼을 누르면 crt 인증서를 다운받을 수 있습니다.

작은 역삼각형 버튼을 누르면 pem 인증서를 다운받을 수 있습니다.




네, rEFIt 개발이 중단되고 rEFInd를 사용해야 하는 상황이죠.

맥에 설치, 혹은 제거하는 법을 알려드리겠습니다.


너무 쉬워서 굳이 글을 쓸까 싶기도 한데...

rEFInd는 맥 전용이 아니기 때문에 맥을 위한 매뉴얼만 깔끔하게 있으면 좋긴 하겠죠!




1. 다운로드

다음 주소로 들어갑니다: http://www.rodsbooks.com/refind/getting.html

맨 위의 A binary zip file을 다운로드 받으시면 되겠습니다.

받으시면 압축을 풀어주세요.




2. 설치

터미널을 열고 해당 폴더의 경로로 들어갑니다.

> cd /Users/계정이름/Downloads/refind*

제 경우에는 다운로드 폴더 안에 있기 때문에 그리로 찾아 들어갔죠.

그리고는 install.sh를 실행하고, 계정 비밀번호를 입력합니다.

./install.sh 

설치 끗!




3. 삭제

네... 터미널에서 아래 명령어를 입력하시면 됩니다.

sudo rm -r /EFI/refind







끝입니다. 헤헤

포고플러그의 벽돌에는 많은 이유가 있습니다.

이 글의 내용이 전부를 커버해 주지는 않는 점 유의해 주시기 바랍니다.


제 경우에는 optware를 설치한 후, 다시 돌려놓기 위해

/etc/init.d/211.sh와 /etc/init.d/rcS.sh를 삭제하는 바람에 벽돌이 되었습니다...


알고보니 rcS.sh는 optware 설치 이전에도 이미 존재하는 파일이었고

optware를 설치하면서 별다른 말도 없이 덮어씌우기 한 것이었죠 -_-;;

포고플러그 기본 시스템을 부팅하는 데 중요한 역할을 하는 파일이라고 합니다;;

그래서 증상은 전원 공급 후 초록 램프의 무한 깜빡임.






인터넷을 뒤져보니 Pogoplug의 부팅 순서는 SATA > 내부 메모리 > USB 라고 합니다.

Series 4의 경우 SATA 포트 대신에 상단에 2.5인치 하드를 장착할 수 있게 되어 있고

이게 내부 메모리보다 높은 우선순위로 부팅 순서가 잡혀있는 것을 확인하였습니다.


준비물은 내용을 전부 삭제해도 되는 2.5인치 하드 디스크와 리눅스입니다.

이 하드 디스크에 archlinux 이미지를 씌운 후, 강제로 부팅시키는 방법을 사용할 것입니다.


이미지 다운로드 (약 300MB)


이미지를 다운받고 zip 압축을 풀면 1.5GB의 고정된 이미지가 나옵니다.






2.5인치 하드를 리눅스에 연결합니다. 리눅스가 없다면 가상머신을 이용하시는게 좋겠죠.

저는 CentOS 6.4 32bit LiveCD 버전을 이용했습니다.


fdisk -l 로 하드의 위치를 파악합니다. 제 경우 /dev/sdb 입니다.

fdisk /dev/sdb 실행하고 o 입력 후 p 를 입력해 모든 파티션이 제거됨을 확인합니다.

q로 fdisk를 빠져나옵니다.


아까 받은 이미지를 하드에 복구합니다. 이미지 경로는 알아서 찾아가시기 바랍니다.

# dd if=pogo_recovery_1_5G.img of=/dev/sdb

입력하면 잠시 리눅스가 멈춘 것처럼 보이게 됩니다. 기다리시면 됩니다.


이제 모든 준비가 끝났습니다. 포고플러그 시리즈 4에 장착 후 부팅하시기 바랍니다.

복구는 인터넷에서 rcS를 받아 복붙해 주시면 되겠습니다.






자료 출처: http://oroispot.blogspot.kr/2013/06/pogoplug-sata.html

네, 기존에 쓰던 삼성 SHS-100V의 패드가 다 벗겨져서 새로운 헤드셋을 구입했습니다.

이름하여 SADES SA-713. 가격은 11,000원.


가성비가 좋다는 소문을 인터넷에서 줏어듣고 구입했습니다.

간단한 리뷰 들어갑니다.




상자 위에 보면 DEEP BASS 라고 자랑스럽게 써 놨네요.

이게 함정입니다... 아래에서 설명드리죠.




벗겨놓고 보니 정수리 패드도 있고, 귀 패드도 두꺼워 보이는게 괜찮죠?




마이크는 구즈넥이라서 원하는 위치로 움직일 수 있습니다...만




여기서 문제점이 발생합니다.

입에서부터 마이크까지 거리가 손가락 두 마디 정도로 아주 멀리 있습니다.


어떻게든 구부려서 살에 닿을 정도로 꺾어도 한 마디 조금 넘게 떨어집니다.

마이크가 입에서 멀다보니, 말을 해도 제대로 안들립니다.




디자인

좋습니다


착용감

안좋습니다. 귀 패드가 딱딱합니다. 금방 귀가 눌려서 아파집니다.

다만 무게는 제법 가벼운 편입니다. 정수리에 가해지는 힘은 약합니다.


음질

DEEP BASS를 강조하는 만큼 정말 저음이 과하게 둥둥대는 느낌입니다.

상대적으로 고음이 잘 안들립니다. 해상력은 일반적인 수준입니다.


마이크

입과의 거리가 너무 멀어서 수음이 잘 안됩니다. 저 멀리서 말하는 것 같이 들립니다.

그리고 이건 뽑기를 잘못한 것 같은데, 전기 노이즈가 들어옵니다. 접지된 데스크탑에서도 테스트 했고

배터리 상태의 맥북에서도 테스트 하였는데 노이지는 계속 들어옵니다.


결론

제가 받은 물건은 단자 접촉 불량까지 겹쳐있었으므로

환불 절차 들어갔습니다. 추천드리지는 않습니다.




같은 돈으로 삼성 SHS-100V 구입하시는 게 더 나은 것 같습니다.

내구성도 좋고, 마이크도 입까지 내려오기에 충분히 길이가 됩니다.

음질도 적당히 분배된 좋은 소리인데, 요즘 신형은 구형에 비해 소리가 바뀐 것 같습니다.

고음역대가 좀 물러서고 중역대가 강조된 소리를 들려줍니다. 하지만 여전히 듣기에는 좋은 소리입니다.

애플은 2009년 10월에서 2011년 4월 사이에 출고된 맥북(폴리카보네이트 화이트)에 대해

하판 고무 벗겨짐 문제로 인해 교체 프로그램을 시행하고 있습니다.

프로그램 영문 제목은 MacBook Bottom Case Replacement Program 입니다.


미국, 일본 등 해외에서는 2가지 방법으로 교체를 진행해 주고 있는데

1. 직접 방문해서 교체 받기

2. DIY 키트를 주문하면 집으로 부품이 배달됨(배송비 무료)


하지만 우리나라는 직접 센터에 방문해야만 교체를 해 주고 있습니다. (역시 보따리상)


▲ 맥북 하판 DIY 키트의 모습




최근 지인으로부터 화이트 맥북을 선물(?)받았는데, 하판 상태가 영 좋지 않았습니다.


마치 맥북 에어에서 가져온 듯한 알루미늄 하판이었고 크기도 잘 맞지 않았는데

알고보니 하판 고무를 완전히 벗겨내면 이런 형태가 된다는 것을 알게 되었습니다.

하지만 이 때까지만 해도 그 사실을 몰랐기에, 비정품 하판으로 착각을 했죠.


저 고무를 완전히 벗겨내면, 맥북 에어의 하판과 같은 재질이 나옵니다.




센터 및 애플에 문의한 결과, 비정품 파트인 경우 교체가 불가능하다는 답을 받았습니다.

외국은 파트를 반납하지 않아도 집으로 DIY 키트를 제공해 주는데 말이죠...


결국 가까운 일본으로 DIY 키트를 신청 후 배송대행을 통해 국내로 들여오기로 했습니다.


https://www.apple.com/kr/support/macbook-bottomcase/


파트 교체 신청 시에는 맥북의 일련 번호를 입력하도록 되어 있었는데, 한국에서 구입한

맥북의 번호를 입력해도 전 세계에서 DIY 키트를 받을 수 있는 것으로 확인되었습니다.


홈페이지 -> 맥북 일련 번호 입력 -> 주소 입력 -> 애플 아이디 로그인 -> 완료


위와 같은 프로세스로 진행되었습니다. 예상 외로 간단해서 놀랐습니다.

저는 배송 대행 업체로 몰테일을 선택했습니다.

아래와 같이 몰테일 도쿄 센터의 주소를 입력하면 그 곳으로 배송됩니다.



신청이 완료되면 절차가 진행되는데,

하루 정도 지나면 배송 관련 이메일이 날라옵니다.



메일에 적혀있는 운송장 번호를 몰테일 신청서에 입력하고 배송 대행을 신청하면 됩니다.


배송 비용은 $17.07 (0.8kg), 약 19,000원이 소모되었습니다.

정품 파트 교체 비용이 9만원인 점을 감안하면 저렴하게 구입한 셈이죠.


(진작 정품인 걸 알았다면 센터에서 무료로 교체했겠지만...)

+ Recent posts