2020년 12월 29일 화요일

6N1+6P1 싱글 앰프의 전면부 커버 씌우기

이 앰프는 컴퓨터 케이스를 재활용하여 만들었던 것이다. 볼륨 노브를 달기가 나빠서 전면 커버를 씌우지 않은 상태로 여러해 동안 사용해 왔다.
언제까지나 이런 모습으로 둘 수는 없어서 약간의 작업을 하였다. 전면부 커버를 버리지 않고 그대로 둔 것이 정말 다행이다. 재료가 매우 두꺼워서 그냥 구멍을 뚫어서는 음량조절용 포텐셔미터를 고정하기 곤란하다. FDD를 가린 창을 제거하고 포맥스판을 이용하여 부품을 고정하였다.
광학 드라이브용 창을 열면 진공관이 뿜어내는 열을 식히기에 좋다. 스프링이 달려서 자동으로 닫히게 되어 있어서 포맥스 조각으로 걸림용 부속을 만들었다.

케이스의 크기로 보아서는 미니어처 진공관 4알이 들어간 푸시풀 앰프를 만들어 넣어도 충분할 정도이다. 단지 가공하느라 구멍을 너무 많이 뚫어서 검정색 커버 전체를 벗겨내기가 창피할 수준이라는 것이다. 이 앰프 섀시에 대한 가장 최근의 작업 이력은 J(oy)앨범 밴드에만 올렸기에 그 링크를 여기에 남겨 둔다.

2020년 12월 26일 토요일

6LQ8 Push-Pull amplifier의 잡음 없애기 성공 - NFB 저항이 까맣게 탄 사연

2020년의 마지막 오디오 DIY 프로젝트에 도전하였다. 잡음이 너무 심하여 앞으로 진공관 앰프를 만드는 취미를 지속하는 것에 대하여 용기를 잃게 했던 바로 그 앰프이다. 작년에 처음 플라스틱 수납함에 대충 만들었을 때에는 음질이 대충 마음에 든다 생각했었지만, 금속 섀시로 옮긴 뒤 주변 소음이 적은 대전 집으로 가지고 왔더니 도저히 들을 수가 없는 수준이었다. 만약 이 문제를 해결하지 못한다면, 여분으로 가지고 있는 10개의 6LQ8 진공관을 무슨 면목으로 바라볼 것인가? 최근 히터 전원선 접지를 통해 43 싱글 앰프의 험을 개선하면서(링크) 6LQ8 PP 앰프의 잡음 제거에 도전해 보기로 하였다. 개조 사항은 다음의 세 가지이다.

첫 번째로 NFB(negative feedback, 부귀환) 신호를 보내는 선은 실드 처리를 하는 것이 좋다고 한다. 이미 PCB에 선을 납땜한 상태라서 실드선으로 교체하는 것은 귀찮으니, 에나멜선을 용수철처럼 말아서 사용해 보기로 했다. 결론만 놓고 말하지면 에나멜선을 꼬는 일이 더 번거로왔다. 어묵 꼬치 막대가 권선용 속심 역할을 하였다.


납을 녹여 지지면 에나멜 피복이 타서 벗겨질 것으로 생각했는데 아무리 해 보아도 납이 붙지를 않았다. 열에 강한 도료가 입혀진 것인지? 출력 트랜스포머를 손으로 감았을 때 썼던 에나멜선은 인두질로 충분히 피복(피막 도료라고 부르는 것이 정확할 것임)을 녹일 수 있었다. 칼로 껍질을 긁어서 벗겨낸 다음 전선을 납땜하여 그라운드에 연결하였다. 두 번째로는 음량 조절용 포텐셔미터(흔히 볼륨이라 부르는 것)의 금속 본체를 접지에 연결하였다. 이것만으로는 잡음이 완전히 줄지 않았다. 마지막으로 앰프 섀시를 접지에 연결하였다. 그랬더니 비로소 거의 완벽한 정적 수준으로 잡음이 사라졌다!
이 앰프는 본체에 전원부를 갖고 있지 않다. 트랜스포머를 포함한 전원부는 별도의 플라스틱 케이스에 들어 있고, 4핀 원형 커넥터가 부착된 케이블을 통해 B전원과 히터 공급 전원(12V 직류 어댑터)이 들어오게 만들었다. 교류 220V의 접지에는 일절 연결되지 않았다.

목적한 바는 달성하였으나 예기치 않게 약간의 사고를 치기도 하였다. 전원을 연결한 상태로 PCB의 커넥터를 잡아 뺀 것이 화근이었다. 소리가 작아지면서 약간 타는 냄새가 나기 시작하였다. 이 상태로 음악을 좀 듣다가 원래 상태로 복구를 하였는데, 나중에 살펴보니 NFB용 저항이 까맣게 탄 것이 아닌가? 다행히 끊어지지는 않았다. 
무슨 일이 벌어졌던 것일까? 한참을 생각하다가 비로소 상황을 이해하게 되었다. 내가 잠시 동안 뽑았던 커넥터는 전원 그라운드에 해당한다. 상식적으로 전원의 한 쪽을 떼어버렸으니 소리가 나서는 안 된다. 그런데 정상 수준에 훨씬 못 미치는 작은 소리가 났다. 그라운드 역할을 한 선이 도대체 무엇인가? 바로 NFB 저항이다. 아래 회로도에서 주황색으로 덧칠한 경로가 그라운드 역할을 한 것이다. 출력 트랜스포머 2차로 들어간 전류는 일부 스피커로도 흘렀겠지만 실제로 큰 소리가 나거나 하지 않았으므로 보이스 코일이 상한 것 같지는 않다. 2차 권선은 두꺼운 선으로 적은 회수가 감긴 상태이니 저항이 매우 작고, 따라서 대부분의 전류는 보이스 코일이 아니라 출력 트랜스포머를 통해 그라운드로 치달았을 것이다.
회로 출처: 제이앨범(http://jalbum.com/board_oBkd16/4523)
그라운드로 흘러갈 전류를 전부 수용한 R10도 혹시 손상을 입었을지 모른다. 소리는 잘 나고 있으니 나중에 기회가 되면 다시 뚜껑을 열고 확인을 해 보면 된다.

전원을 넣어 작동하는 중에 함부로 커넥터를 뽑거나 꽂는 것은 대단히 위험한 일임을 깨달았다. 하지만 작은 사고를 통해서 이론 공부만으로는 도저히 알 수 없는 산 지식을 얻었으니 성과가 전혀 없었다고 할 수는 없다.

히터 공급선을 전원의 그라운드에 연결하는 것도 험 제거를 위해 대단히 중요하다. 6LQ8 PP 앰프에서는 PCB내에서 패턴의 일부를 공유한다. 다음 그림은 이해를 돕기 위해 내가 그린 것이다. 검정색 두꺼운 사각형은 PCB의 가장 바깥쪽에 위치한 그라운드 패턴이다. 왼쪽 진공관의 히터 단자 중 하나를 (-)에 연결하는 방법은 점선과 같이 점퍼선을 연결하거나, 또는 타원으로 표시한 곳을 납으로 이어 버리는 것이다. 나는 후자의 방법을 택하였다. 만약 PCB 바깥에서 히터 공급선의 (-)와 B전압 (-)를 연결했다면(회색 선), 이는 바람직하지 못한 그라운드 루프를 형성할 것이다. 당연히 이런 연결은 하지 않았다.
히터는 직렬로 연결하여 점화한다. 12.6V를 공급하는 것으로 표시하였지만, 실제로는 직류 12V SMPS 어댑터를 사용하였다.
용기를 잃지 말고 앞으로도 진공관 앰프를 만들고 수정해 나가는 취미를 계속 해야 되겠다.


2020년 12월 24일 목요일

우분투 18.04의 vi에서 편집 모드일 때 화살표키를 누르면 영문 대문자가 나타나는 현상에 관하여

사무실에서 쓰는 CentOS 7의 vi(실제로는 vim의 symbolic link인 것으로 알고 있다)에서는 문제가 없는데, 집에서 사용하는 노트북에서는 편집 모드에서 화살표키를 누르면, B/A/D/C가 입력되어 상당히 불편하다. 꼭 ESC 키를 눌러서 command mode로 빠져나온 다음 화살표키를 눌러서 원하는 위치로 이동해야만 한다.

구글 어딘가에는 당연히 해결 방안이 있을 것으로 생각하였다. 어렵지 않게 답을 얻었다.

[StakExchange] Hitting arrow keys add characters in vi editor

홈 디렉토리에 .vimrc 설정 파일을 만들어서 'set nocompatible'이라고 한 줄을 써 넣으면 끝이다. vi가 아닌 vim이 설치된 상태라면 .exrc에 같은 내용을 써 넣으면 된다고 한다.

이 컴퓨터에 설치된 것은 vi인가, vim인가? vim라는 이름으로는 실행할 수 있는 파일이 없다. 그러면 정말 예전에 쓰던 vi란 말인가? 확인을 해 보니 vim-tiny(Vi IMproved - enhanced vi editor - compact version)가 설치된 것이 맞다. 그런데 이는 오로지 'vi'라고만 쳐야 실행이 된다.

vi가 다른 명령어의 심볼릭 링크는 아닌지 궁금하여 조금 더 추적을 해 보았다.

$ which vi
/usr/bin/vi
$ ls -l /usr/bin/vi
lrwxrwxrwx 1 root root 20  8월 15 11:15 /usr/bin/vi -> /etc/alternatives/vi
$ ls -lt /etc/alternatives/vi
lrwxrwxrwx 1 root root 17  8월 15 11:14 /etc/alternatives/vi -> /usr/bin/vim.tiny

명령행에서 vi를 입력하면 최종적으로는 같은 디렉토리에 있는 vim.tiny가 실행됨을 알 수 있다.

화살표키를 눌렀을 때 영문 대문자가 삽입되는 문제의 해결책을 국문 사이트에서 찾아보면 vi를 버리고 vim을 쓰면 된다고 한다. ~/.vimrc 파일에 손을 대라는 말도 없다. 우분투 18.04에 설치된 vim.tiny는 vi도 아니고 vim도 아닌 어정쩡한 상태인 것 같다.

/etc/alternatives 이하의 파일들은 update-alternatives라는 명령에 의하여 관리되는 것들이다. CentOS에서는 alternatives 명령을 사용하여 java의 여러 버전을 관리했던 기억이 난다. vi의 상태는 어떠한지 이 명령을 써서 확인해 보았다.

$ update-alternatives --query vi
Name: vi
Link: /usr/bin/vi
Slaves:
 vi.1.gz /usr/share/man/man1/vi.1.gz
 vi.fr.1.gz /usr/share/man/fr/man1/vi.1.gz
 vi.it.1.gz /usr/share/man/it/man1/vi.1.gz
 vi.ja.1.gz /usr/share/man/ja/man1/vi.1.gz
 vi.pl.1.gz /usr/share/man/pl/man1/vi.1.gz
 vi.ru.1.gz /usr/share/man/ru/man1/vi.1.gz
Status: auto
Best: /usr/bin/vim.tiny
Value: /usr/bin/vim.tiny

Alternative: /usr/bin/vim.tiny
Priority: 15
Slaves:
 vi.1.gz /usr/share/man/man1/vim.1.gz
 vi.fr.1.gz /usr/share/man/fr/man1/vim.1.gz
 vi.it.1.gz /usr/share/man/it/man1/vim.1.gz
 vi.ja.1.gz /usr/share/man/ja/man1/vim.1.gz
 vi.pl.1.gz /usr/share/man/pl/man1/vim.1.gz
 vi.ru.1.gz /usr/share/man/ru/man1/vim.1.gz

이제야 좀 이해가 간다.

2020년 12월 23일 수요일

Mendeley Profile 서비스 종료

얼마 전부터 Medeley의 내 프로파일 링크를 클릭하면 찾는 페이지가 없다는 404 에러 메시지가 나타나고 있다. 혹시 내가 프로파일 설정을 비공개로 한 것이 아닌가해서 해당 메뉴를 가 보았지만 특별히 이상한 점은 눈에 뜨이지 않았다.

404 에러가 뜬 웹페이지의 중간쯤에 이런 글귀가 보인다.

2020년 11월 2일부터 몇 가지 서비스를 종료한다는 뜻이다. 항상 그렇듯이 '고객들에게 핵심 가치를 제공하는데 집중'하기 위하여 그렇다고 한다. Refocusing이라는 낱말을 써서 완곡하게 표현하는 서비스 중단의 상세한 내역은 여기(또는 블로그)에 나온다. 그들이 더욱 집중하려는 핵심 가치는 다음의 세 가지이다.
  • Reference management(현재 내가 가장 즐겨 사용하는 기능)
  • Research data management
  • Citation solutions
한 달에 겨우 4.99 달러를 지불하는 Plus('Great for students!') 구독자로서 뭘 그렇게 많이 바라겠는가? 논문 PDF를 아직까지는 부족함 없이 업로드하여 관리하는 것으로 만족을 해야 한다.

논문과 관련한 나의 업적 사항은 ORCID에서 공개하는 것으로 만족하자. 여기에 들어가면 Loop profile이나 Scopus Author ID도 보인다. 각 사이트에 따라서 집계된 논문의 총 수가 약간 다르다. 아마도 기준이 달라서 그런 것으로 생각된다. 너무 늦기 전에 정리할 필요는 있다. Google Scholar는 자동으로 추가된 논문을 수작업으로 종종 정리하는데 이것 역시 완벽한 상태는 아니다.

Mendeley Data를 쓰려면

FigShare와는 달리 Mendeley Data는 Elsevier에서 출판되는 저널에 실을 논문에 부속되는 데이터를 저장하는 공간인 것처럼 보인다. 그러나 항상 논문이 accept되는 것도 아니고 상황에 따라 목표 저널을 바꾸어 다시 투고할 수도 있다. 그러므로 데이터셋을 올릴 시점에 저널을 지정한다는 것은 말이 되지 않는다. 다만 Elsevier 웹사이트에서 데이터셋에 대한 검색을 편하게 할 수 있다는 것이다. 무료로 올릴 수 있는 데이터셋의 최대치는 10 GB라고 한다. 이를 사용하는 것을 고려해 보자.

좀 더 살펴보니 논문이 공개될 때 데이터셋도 일반에 공개되며, 이때에 비로소 DOI가 부여된다고 한다('When will my dataset be made available online?'). 저널과 관계없이 공개할 데이터셋이라면 Mendeley Data에 올리는 것이 적합하지 않은 것 같다.

또 다른 대안인 Zenodo는 어떠한가? 이 저장소는 CERN이라는 약자로 잘 알려진 유럽입자물리연구소의 openAIRE 프로그램에서 제공한다. Zenodo FAQ site에서 사용에 따른 제약이나 용량(50 GB) 등을 알아보아야 되겠다.

내가 아는 곳 외에도 연구 데이터의 공개 저장소는 꽤 많다. 다음 그림은 Mendeley Data에서 가져온 것이다.



2020년 12월 22일 화요일

[PulseAudio] default sound card를 찾아보자

오늘의 포스팅은 ArchLinux 위키의 PulseAudio/Examples 페이지를 참조하였다. 부팅 후 USB 단자에 아무런 사운드 기기를 연결하지 않은 상태에서는 당연히 내장 사운드 카드를 기본 기기로 인식할 것이다. 소스(source), 즉 입력 기기가 무엇인지 알아보자.

$ pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'
  * index: 0
	name: <alsa_output.pci-0000_00_1b.0.hdmi-stereo.monitor>
		device.string = "0"

인덱스 왼쪽의 별표('*')는 그 기기가 default input임을 의미한다. 이제 USB 마이크로폰을 연결한 뒤 같은 명령을 내려 보자.

$ pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'
    index: 0
	name: <alsa_output.pci-0000_00_1b.0.hdmi-stereo.monitor>
		device.string = "0"
    index: 1
	name: <alsa_output.usb-Burr-Brown_from_TI_USB_audio_CODEC-00.analog-stereo.monitor>
		device.string = "1"
  * index: 2
	name: <alsa_input.usb-Burr-Brown_from_TI_USB_audio_CODEC-00.analog-mono>
		device.string = "hw:1"

기본 입력은 USB 마이크로폰으로 바뀌었으며, device 명칭은 hw:1이다. 어떤 경우든 웹캠 바로 곁의 내장 마이크가 소스의 목록에 나타나지는 않는다. cheese를 작동시켜 보았다. USB 마이크를 연결하지 않으니 녹화는 되지만 소리가 녹음되지 않는다. 이것도 이상한 일이다. 분명히 이 컴퓨터를 사용해서 내장 웹캠과 마이크만으로 화상 회의를 했던 것 같은데... 그게 아니라 헤드셋을 꽂고 회의를 했었나? 이젠 나의 기억을 믿지도 못하겠다.

USB 기기를 뺐다 꽂았다를 반복하면 index 번호가 차례로 증가한다. 그러나 USB 기기를 뺀 상태에서의 디폴트 소스 인덱스 번호는 계속 0이다.

2020년 12월 21일 월요일

우분투 명령행에서 USB 마이크로폰으로 녹음하기

SoX 유틸리티의 rec 명령어를 써서 USB 마이크 입력 녹음을 해 보고 싶었는데 사용법이 너무 복잡하여 도대체 어떻게 해야 하는지를 이해하기 어렵다. 검색을 통해서 alsa-utils에 포함된 프로그램으로서 사용하기 무난한 arecord를 쓰기로 하였다. 컴퓨터에 연결된 입력 디바이스의 샘플 레이트를 먼저 확인해 본다.

$ pactl list short sinks
0	alsa_output.pci-0000_00_1b.0.hdmi-stereo	module-alsa-card.c	s16le 2ch 44100Hz	SUSPENDED
1	alsa_output.usb-Burr-Brown_from_TI_USB_audio_CODEC-00.analog-stereo	module-alsa-card.c	s16le 2ch 44100Hz	SUSPENDED

44.1 kHz라고? 48kHz로 알고 있는데 무슨 영문인지 모르겠다. 's16le'는 signed 16-bit little endian을 의미하는 sample format이다. arecord에서는 -f로 이를 지정한다. 특별히 지정하지 않으면 unsigned 8-bit('-f U8'과 같다)로 녹음이 되는데 음질은 형편없다.

다른 옵션에 대하여 심각하게 생각하지 않고 5초간 마이크로 녹음을 시도한다. 입력 디바이스를 명령행 옵션으로 지정하지 않았음에도 불구하고 원하는대로 마이크가 작동될 것인가?

$ arecord -f S16_LE -r 60000 -d 5 test.mp3
녹음 WAVE 'test.mp3' : Signed 16 bit Little Endian, 60000 Hz 비율, 모노
$ play test.mp3 
play WARN alsa: can't encode 0-bit Unknown or not applicable

test.mp3:

 File Size: 600k      Bit Rate: 960k
  Encoding: Signed PCM    
  Channels: 1 @ 16-bit   
Samplerate: 60000Hz      
Replaygain: off         
  Duration: 00:00:05.00  

In:100%  00:00:05.00 [00:00:00.00] Out:300k  [      |      ]        Clip:0    
Done.

60 kHz(-r  또는 --rate=#, 단위는 Hz)로 녹음이 잘 되었다. 가능한 값이 아닌데 어떻게 녹음이 된 것일까? 미스테리는 차차 풀기로 한다. 녹음할 시간을 미리 지정하기 싫다면 -d 0 옵션을 주어 녹음을 개시한 뒤 Ctrl+C를 눌러서 종료하면 된다. 기본값이 0이니 아예 -d 옵션을 주지 않아도 된다. 저장할 파일의 확장자에 따라서 출력 파일의 형식은 자동으로 결정된다.

입력을 받을 오디오 기기에 대한 정보를 전혀 주지 않았음에도 불구하고 알아서 USB 마이크로 입력이 잘 되었다. 아마도 PulseAudio가 개입하여 우선 순위 입출력 기기를 알아서 결정하고 있는 듯하다. USB 마이크로폰이 꽂혀 있지만 노트북 컴퓨터의 내장 마이크로폰을 사용하여 녹음하게 만들 수는 없을까? -D hw:#,#(select PCM by name) 옵션으로 디바이스를 선택할 수 있다고 하는데, (0.0)으로는 잘 되지 않는다. 

$ arecord -f S16_LE -r 44100 -d 5 -D hw:0,0 test.mp3
녹음 WAVE 'test.mp3' : Signed 16 bit Little Endian, 44100 Hz 비율, 모노
arecord: set_params:1305: 사용할 수 없는 채널 수입니다
hyjeong@CQ61:~$ arecord -f S16_LE -r 44100 -d 5 -D hw:1,0 test.mp3
녹음 WAVE 'test.mp3' : Signed 16 bit Little Endian, 44100 Hz 비율, 모노
$ arecord -f S16_LE -r 60000 -d 5 -D hw:1,0 test.mp3
녹음 WAVE 'test.mp3' : Signed 16 bit Little Endian, 60000 Hz 비율, 모노
경고: 비율이 정확하지 않습니다(요청함 = 60000Hz, 가져옴 = 48000Hz)
         플러그인 를, 연결해보십시오

-D hw:1,0이 USB 마이크로폰을 가리키는 것은 맞다. 그런데 이를 지정하지 않으면 -r 60000이라는 비상식적인 샘플링 레이트로 녹음이 되지만, -D hw:1,0을 지정하면 정확하지 않다면서 자동으로 48 kHz를 선택한다. 

-D default를 입력하면 여전히 USB 마이크로폰으로 녹음이 된다. 분명히 현 상태에서는 hw:1,0이 default인 것이 맞다. 컴퓨터 내장 마이크로는 녹음을 할 수가 없는가? 내가 뭘 잘못 알고 있는 것인지...

디바이스를 지정하지 않은 상태에서 녹음을 하면서 PulseAudio Volume Control을 열어 보았다.

내장 마이크에 해당하는 입력 디바이스는 보이지 않는다. 에혀~ 나도 모르겠다.

Audacity에서 USB 마이크로폰으로 녹음하는 것도 미스테리!

웹캠 캡처용 프로그램(예: Guvcview)으로 녹음을 할 때에는 PulseAudio로 오디오 콘트롤을 설정하는 것 말고는 특별히 할 일이 없다. 그러나 Audacity로 마이크 입력 녹음을 하려면 JACK 서버를 미리 구동해야 한다. 아, 정말 모르겠다! 유튜브에서 재생되는 음악이나 악기(가상악기 또는 MIDI 장비의 아날로그 출력)를 audacity에서 녹음할 때에는 JACK의 도움을 필요로 하지 않았었다. 올해 내내 리눅스에서 음악을 다루는 - 단지 듣기만 할 때에는 별다른 문제가 없음 - 문제와 씨름을 하고 있는데 아직도 많은 구석이 미스테리로 남아 있다. PulseAudio 설정 예제를 보고만 있어도 머릿속이 하얗게 표백되는 것 같은 느낌이 든다.

ITC의 최종 판결에서 균주는 영업비밀이 아니라는 견해에 대하여

뉴스에 의하면 ITC의 최종 판결문에서 균주는 영업비밀이 아니라고 명시했다고 한다. 아직 공개된 판결문을 보지 못하였으니 정확한 판단을 내리기는 이르다. 많은 사람들은 '균주는 자연 어디서든 채취 가능하고 따라서 주인이 있을 수 없으며, 때문에 도용이라는 말이 성립되지 않는다'라고 해석한다는 것이다. 따옴표 안의 글은 의학신문 기자수첩 코너에 오늘 올라온 김영주 기자의 글(링크)에서 인용한 것이다.

자연계에 존재하는 생명체의 경제적 활용에 대해 독점적 권한을 주는 것은 요즘의 정서로는 타당하지 못하다. 다만 그 생명체에 대하여 고도한 수준의 기술을 가하여 새로운 용도를 창출했다면 그 용도에 대하여 특허권을 줄 수는 있을 것이다. 예를 들어 가 송이(버섯)(학명 Tricholoma matsutake)를 우리나라에서 처음으로 발견하였고 음식에 넣어 먹으니 대단히 맛이 좋다는 것을 알아냈다고 치자. 그렇다고 하여 다른 사람이 송이를 채취하거나 먹는 것을 금지할 수 있을까? 그럴 수 없다(특별한 용도, 즉 요리법에 대해서는 실용신안을 받을 수 있을지도 모르겠다). 송이는 자연계에 원래 있던 생명체이기 때문이다. 하지만 깊은 산에서 송이를 찾는 것은 매우 수고스러운 일이다. 상당한 수준의 경험이 필요하고, 험한 산을 다니다가 위험에 빠질 수도 있다. 따라서 내가 채취한 송이를 소중히 지키려는 것은 당연하다. 내가 송이를 발견하여 이를 남들보다 더 쉽게 찾아내고 또한 상하지 않게 잘 채취하는 나름대로의 비법을 알아내었기에 이를 함부로 남에게 알려주지 않았다. 송이를 잘 가공하여 비싼 식재료로 인기리에 파는 것이 알려지면서, 몇몇 사람들이 송이를 구하러 산으로 올라가기 시작하였고, 조금씩 장터에 물건이 나오게 되었다. 송이의 값이 좀 내려가는 것이 아쉬웠지만, 이것을 막을 수도, 막을 이유도 없다.

만약 내가 수고스럽게 산에서 채취하여 잘 다듬은 다음 창고에 보관하던 송이를 누군가 훔쳐갔다면 어떻게 될까? 당연히 절도죄가 성립한다. 송이를 훔쳐간 도둑이 이렇게 말한다.

송이는 산에 가면 얼마든지 있다. 아니, 이젠 가게에 가서 살 수도 있다. 온 세상의 송이가 다 네 것이냐? 나는 네 창고의 송이를 훔쳤지만, 그 송이는 어차피 너의 것이 아니었다. 따라서 나는 너에게 잘못한 일이 없다.

이것이 정당한 주장인가? 내가 송이를 세계에서 처음 발견한 사람이지만 나는 온 세상에 자생하는 송이가 나 내것이라고 하지 않았다. 하지만 내가 내 소유의 산에서 힘들여 채취하여 팔기 위해 정성스럽게 다듬어서 창고에 보관하고 있는 송이는 내 소유물이므로, 이를 훔쳐간 행위에 대해서는 얼마든지 비난을 하고 법에 의해 처벌해 달라고 요청할 수 있다. 피해자인 나의 입장에서 바라본 사건의 본질은 이것이다. 다만 공소시효가 지났다면 형법에 호소할 수는 없을 것이다. 

안타까운 것은 내가 산에서 최초로 송이를 가져오게 된 경위 자체에 대하여 흠집을 내려는 사람들이 많다는 것이다. 그것이 전부가 아니다. 과학적 증거를 들어서 옆마을 김서방이 내 송이를 훔쳐간 것이 틀림이 없다는 것이 밝혀졌으나, 몇 년의 다툼을 거치는 동안 나도 공격을 많이 받았다. 우리 집에서 일했던 일꾼이 김서방네 집으로 옮겨가서는 그동안 우리 집에서 시들어 빠진 송이를 최상급품이라고 속여서 팔았다고 제보를 한 것이다. 김서방이 이제와서 돌연히 제보를 한 경위도 석연치 않다.

나는 단지 송이 도둑을 잡기 위하여 싸움을 걸었던 것인데, 그것이 길어지면서 점점 본질이 흐려지기 시작하였다. 정의를 구현하겠다고 시작한 일이 모두에게 고통을 주는 것 같다. 나에게 돈을 빌려주었던 사람들도 불안해하기 시작하였다. 이제는 진짜 모르겠다.

2020년 12월 19일 토요일

우분투용 비디오 캡처 프로그램 Guvcview 테스트하기(동영상 링크 포함)

우분투에서 기본 제공하는 cheese 프로그램을 이용하여 새로 구입한 웹캠(아이리버 IPC-HD01 V2)과 USB 콘덴서 마이크로폰(MXL Tempo)으로 녹화를 해 보았다. 화면은 4:3 비율로 고정이고 화질도 매우 좋지 않으며, 소리도 무척 작았다. 결과 파일은 webm이라는 매우 생소한 확장자를 갖는다. 소리가 너무 작아서 조정이 필요한 수준이다. 웹캠의 자체 마이크로는 꽤 큰 음량으로 녹음이 되지만 주변의 잡음이 그대로 들어와서 듣기에 매우 거북하였다. Audacity에 webm 파일을 마우스로 끌어다 놓으니 일반 오디오 파일을 여는 것처럼 되었다. 구간을 지정하여 음량을 키울 수는 있다.

'치즈(cheese)'보다 더 나은 비디오 캡처 프로그램은 없을까? 검색을 해 보니 Guvcview라는 것이 매우 편리하다고 한다.

[QA Stack] 비디오 캡처에 치즈보다 좋은 점이 있습니까?

자동 번역이 된 글 제목은 너무 어색하다. 본문은 원문을 볼 수 있는 '언어 토글' 기능이 있지만 제목은 그렇지 못하다. 어쨌든 이 글을 참조하여 Guvcview라는 프로그램을 설치하였다.  

$ sudo add-apt-repository ppa:pj-assis/ppa
$ sudo apt-get update
$ sudo apt-get install guvcview

Guvcview는 도대체 뭐라고 읽어야 하나? 정식 명칭은 GTK+ UVC Viewer이다. UVC는 또 뭔가? USB Video Class Driver의 약자인 듯하다. 명령행에서 guvcview를 입력하여 실행을 해 보았다. 

 

Video Controls 탭에서 해상도를 원하는 수준으로 쉽게 맞추었다. Audio Controls 탭에서는 Audio API를 Portaudio로, Input Device는 'Pulse'(아마도 PulseAudio를 뜻할 것이다)로 맞추어서 녹화를 해 보았다. 녹화가 완료된 파일의 확장자는 mkv라는 것이다. 이 파일 형식은 '마트료시카 멀티미디어 컨테이나'로서 비디오, 오디오, 그림, 자막트랙을 하나의 파일에 제한 없이 담을 수 있는 자유 오픈 컨테이너 양식이라 한다. 러시아의 전통 인형인 마트료시카가 맞다. 이 파일을 더블 클릭하니 parole video player에서 매우 훌륭한 화질과 음질로 재생이 되었다. 음량도 별도로 키울 필요가 없었다. 

Guvcview에서 아이리버 웹캠과 MXL Tempo 콘덴서 마이크 중 원하는 것을 고르지는 못하였다. 어떻게 해야 할까? Audio API를 PULSEAUDIO로 하였더니 Input Device에 비로소 아이리버 웹캠(스테레오)과 MXL Tempo(모노)가 목록으로 보이기 시작하여 원하는 것을 고를 수 있었다. 두 가지 마이크를 전부 테스트해 보았으나, 아이리버 웹캠에서 스테레오로 녹음이 된다는 느낌이 들지는 않았다.

구글 포토에서는 1080p 이하의 동영상이라면 무제한으로 저장이 가능하다고 한다. 약 1분 분량의 테스트 동영상을 녹화하여 그대로 구글 포토에 올린 뒤 더블 클릭을 하니 크롬에서 그대로 재생이 된다. 해상도는 1280x720이니 무제한 저장의 범주에 들어갈 것이다. 동영상 링크는 다음과 같다. 이 블로그 포스트에 임베드할 수도 있겠으나 html 소스를 어떻게 작성하는지를 아직 몰라서 링크로 대신한다. 업로드하기 전의 mkv 파일 용량은 43 MB였는데 크롬에서 이를 다시 다운로드하니 5.9 MB의 mp4 파일이 되어 있었다. 구글 드라이브에 올리면 원본 파일의 형태(확장자)를 그대로 유지하는 것 같다.

https://photos.app.goo.gl/TUu8AQT8n53GSEZs9

그저 테스트를 위해 찍은 동영상을 유튜브에 올릴 필요는 없을 것이다. 유튜브에는 좀 더 영양가가 있는 내용을 올리도록 하자. 해 보니 상당히 재미있다!