반응형

아나콘다 에러 해결하기

 

UPDATA : 2019.11.20

최근 맥북의 OS업데이트와 아나콘다의 버전 업데이트가 비슷한 시기에 있었습니다.

덕분에 정확하게 누구 문제인지는 모르겠지만, 오랜만에 Jupyter notebook을 사용해보려고하니 경로에러가 계속 발생하더군요.

 

그냥 절대경로 잡아서 수행하다가 불편함이 많아 싹 지우고 클린설치했는데 그래도 문제가 있더군요...

 

 

이런식으로 아나콘다 관련 명령을 입력했음에도 실행이 안되는 문제가 있었습니다.

 

 

1. 경로 확인하기

맥에서 Anaconda의 명령어 경로는 이전부터 동일했었습니다.

 

/Users/<사용자명>/anaconda3/bin/ 명령어

 

위와같은 형태였는데, 이번에 다시 확인해보니 이 경로가 달라졌던것을 볼 수 있었습니다.

 

/Users/<사용자명>/opt/anaconda3/bin/명령어

 

위와같이 중간에 'opt'라는 폴더가 지나가는 것을 볼 수 있었습니다.

 

그럼 환경변수는 잘 되어있는가?

 

 

왠지 모르지만, 아나콘다의 경로가 변함없는 것을 볼 수 있었습니다.

 

그럼 왜 이렇게 됬을까?

 

 

 

 

2. ~/.bash_profile 확인하기

 

리눅스 시스템에서 부팅과 함께 수행할 명령을 적어두는 bash_profile을 확인해보았습니다.

 

흠... 잘 보시면, 중간에 < #added by Anaconda3 2019.10 installer > 라는 부분이 있습니다. 해당 부분을 보게되면 경로설정 영역에 분명하게 '/opt/' 라는 부분이 존재합니다.

 

즉, opt폴더가 경로상에 존재한다는 것을 anaconda3를 설치하는 과정에서 시스템에게 알려주려했다는 것을 볼 수 있습니다.

 

하지만, 여기서 문제가 있죠...

 

일반적인 리눅스라면 문제가 없었겠지만, 저의 PC는 맥...

 

부팅시 bash_profile을 확인하는 것이 아니라, zshrc파일을 확인하게됩니다...

 

 

 

3. ~/.zshrc 파일 확인

 

실행결과 이전에 옛날 아나콘다의 환경변수를 설정하는 부분만 존재하고 새롭게 추가된 'opt'폴더에 대한 명시가 없는 것을 볼 수 있습니다.

 

따라서 기존의 것은 제거하고, bash_profile에서 추가되어있던 opt관련 부분을 복사하여 여기에 추가해주겠습니다.

 

아래는 추가한 모습입니다.

 

변경한 모습

 

이 후 확실한 확인을 위해 재부팅을 해주었습니다.

 

부팅 후 환경변수를 확인해보면 아래와같이 잘 적용된 것을 볼 수 있습니다.

 

 

환경변수도 잘 들어갔고 conda와 같은 명령어도 아래와같이 정상적으로 실행되는 것을 볼 수 있었습니다.

 

 

 

 

문제해결~~~~~!

반응형
반응형

WAV 음악파일 속도 변형

 

 

1. WAV 파일이란?

WAV(웨이브 오디오 포맷, Waveform audio format)은 마이크로소프트와 IBM의 오디오 파일 표준입니다.

 

덕분에 해당 포맷에 대해 상세하게 적혀있는 사이트들과 각종 pdf자료들이 존재합니다. 아래는 그중 한 사이트입니다.

 

http://soundfile.sapp.org/doc/WaveFormat/

 

Microsoft WAVE soundfile format

WAVE PCM soundfile format The WAVE file format is a subset of Microsoft's RIFF specification for the storage of multimedia files. A RIFF file starts out with a file header followed by a sequence of data chunks. A WAVE file is often just a RIFF file with a

soundfile.sapp.org

 

 

 

 

아래는 WAV 파일에 대한 포맷 정보입니다.

 

WAV 파일 포맷

 

WAV 파일은 크게 세 개의 영역으로 분류되는 것을 볼 수 있으며, Big Little dndian을 섞어 사용하는 것을 볼 수 있습니다.

 

Python에서 WAV 파일을 불러와 위의 포맷을 확인해보겠습니다.

 

binary read

단순히 샘플 파일을 하나 갖고 와서 위와 같이 열어보았습니다.

 

이를 위 사이트(http://soundfile.sapp.org/doc/WaveFormat/)에 나와있는 정보와 비교해보며 보겠습니다.

 

 

 

 

2. First Block - RIFF 영역 헤더

 

먼저 Little endian과 Big endian에 따라 hex값을 출력해주는 함수를 만들어주었습니다.

 

 

다음으로 위의 사이트에 나와있는 첫 번째 블록 정보를 보았습니다.

 

ChunkID : "RIFF"라는 문자를 ASCII로 갖고 있음. (big-endian기준 : 0x52494646)

ChunkSize : 전체 파일크기 중 ChunkID와 ChunkSize부분인 8Byte를 제외한 전체 크기를 말함

Format : "WAVE"라는 문자를 갖고 있음 (big-endian기준 : 0x57415645)

 

이번에는 파이썬에서 보겠습니다.

 

위와 같이 홈페이지에 나와있는 것과 동일한 ChunkID와 Format값을 갖고 있는 것을 볼 수 있으며, ChunkSize의 값을 10진수로 표시하고 8을 더해 전체 파일크기와 비교해보겠습니다.

 

예측되는 전체 파일크기
실제 파일정보

 

보시는 것과 같이 동일한 파일크기를 갖는 것을 볼 수 있습니다.

 

 

 

 

3. Second Block - fmt 영역 헤더

 

다음은 두 번째 블록 정보입니다.

Subchunk1ID : "fmt "값을 갖고 있음. (big-endian기준 : 0x666d7420)

Subchunk1Size : Subchunk1의 크기

AudioFormat : PCM 방식이면 1

NumChannels : Mono = 1, Stereo = 2

SampleRate : 샘플링 주기

ByteRate : SampleRate * NumChannels * BPS/8

BlockAlign : NumChannels * BPS/8

BPS : 초당 비트 값

Extra Data

 

마찬가지로 파이썬에서 실제 데이터로 보겠습니다.

 

각각의 데이터는 Hex데이터임을 생각하시고 봐주세요.

 

위의 데이터를 보게 되면, 해당 음원(wav파일)은 아래와 같은 정보를 갖고 있습니다.

 

PCM 방식 파일 압축, 스테레오 음원, 샘플링 주기는 44100Hz(0xac44), BPS는 16bit

 

위 정보를 기반으로 음원 재생 프로그램은 노래를 재생하게 되는 중요한 정보입니다.

 

 

 

 

4. Last Block - data 영역

 

마지막 블록입니다.

 

Subchunk2ID : "Data"라는 값을 갖고 있음. (big-endian 기준 : 0x64617461)

Subchunk2Size : Subchunk2의 크기를 말합니다.

Data : 실제 음원 정보를 갖고 있는 데이터입니다.

 

Data 영역은 Little endian으로 구성되어있는 모습 그대로 표시한 것입니다.

 

 

이렇게 해서 일단 WAV 파일의 정보를 모두 확인해보았습니다.

 

다음장에서는 해당 데이터를 수정하여 음원을 변경하는 것을 보여드리겠습니다.

반응형
반응형

DHCP 깊게 알아보기

 

 

1. 원하는 IP주소 할당받기

DHCP Request Message를 자세히 보게되면 아래와 같은 [Requested IP Address]라는 항목이 존재합니다.

 

DHCP Request Option

 

DHCP Server가 할당하기를 원하는 IP주소가 아닌 다른 IP주소를 요청할 경우 어떤 응답이 올지 궁금하지 않습니까?

(크흠... 저는 궁금했습니다.)

 

 

확인해보기

위의 상황을 만들어보기 위해서 먼저 Jupyter notebook을 열었습니다.

IP주소를 일단 할당받을 이후에 새로운 IP주소를 요청하는 형태로 진행해보았습니다.

 

 

 

먼저 기존의 DHCP PACKET을 그대로 복제해서 전송해보았습니다.

 

DHCP PACKET

 

Wire Shark를 이용하여 Packet Data를 Hex Stream으로 복사한 후 해당 데이터중 dhcp의 데이터 부분만 뽑아내어 그대로 전송하였습니다.

 

여기서 특이한 부분은 UDP부분에 들어가는 CheckSum값이 틀리게 전송되고 있다는 것이었습니다.(복제되기전 패킷부터)

 

덕분에 Checksum값을 계산해주지 않고 그냥 전송할 수 있었습니다. ㅎㅎ

 

socket은 UDP이기 때문에 DGRAM으로 열어주시고, 68번 port를 Source로 67을 Destination으로 설정해주었습니다.

 

< 68번 Port로 Socket을 Bind를 해준 상태로 와이파이를 연결하면 IP주소를 받아오지 못할 수 있습니다. >

< 중간에 와이파이를 다시 잡아야할 필요가 있다면, socket close 후 진행해주세요 >

 

 

어찌되었든 패킷을 복제해서 전송해봤는데, ACK가 정상적으로 수신되는 것을 볼 수 있었습니다.

 

이제 DHCP의 메시지 중 Request IP 부분을 수정해서 다시 전송해보겠습니다.

 

IP Address 영역
Hex Data 중 IP 영역

ac(16) : 172

1e(16) : 30

01(16) : 01

23(16) : 35

 

위의 데이터의 마지막 23(16)을 64(16)으로 변경해서 전송해보겠습니다.

(64(16)은 10진수로 100입니다. 즉, 172.30.1.100 으로 요청)

 

실행결과

 

실행결과 위와같이 NAK 메시지를 수신하였습니다.

 

NAK는 'Negative ACK'를 의미합니다. 즉, 싫다는 뜻입니다. 힝...

 

NAK...

그 이후로 IP주소를 변경해가며 요청해보았지만, 전부 거절당했습니다.

 

서버측에서 DHCP Discover 단계에서 허가해준 IP주소에 한정해서 할당이 가능한듯합니다.

 

 

 

2. DHCP Discover 요청

위에서의 실패를 발판삼아 이번에는 Discover 요청부터 수행해보겠습니다.

 

마찬가지로 Discover 패킷을 복제해보았습니다. (역시나 Checksum은 맞지 않습니다.)

 

DHCP Discover

 

DHCP Discover에 대한 응답도 잘 왔습니다. (DHCP Offer)

 

다만, Discover의 경우 IP주소를 요청할 뿐 원하는 IP주소를 선택할 수 없으며, 동시에 이미 IP주소를 할당받은 상태로는 아무리해도 결과가 동일합니다.

 

고민이군요...

 

테스트하는 공간에 카페이다보니 공유기 설정창에 접속해서 만져보기가 힘드네요.

 

추후에 다른 환경에서 확인 후 이어서 포스팅 하겠습니다 ㅎㅎ

반응형

+ Recent posts