내 친구가 서버를 사용하여 네트워크를 통해 CDROM 장치를 내보내려고 했지만 nbd데이터 CD에서는 작동하지만 오디오 CD는 실제로 일반 데이터 디스크처럼 작동하지 않는다는 것을 발견했습니다. 그리고 나는 파일 시스템의 유무에 대해 말하는 것이 아니라 원시 블록 수준 액세스에 대해 이야기하고 있습니다.
나는 오디오 CD가 실제로 파일 수준에서 해석될 수 없다는 것을 이해하지만, 따라서 실제로는산, 나는 여기에 오디오와 관련된 추가 정보가 많이 포함되어 있다는 것을 이해하고 데이터 디스크와 같은 방식으로 실제로 CRC가 없다는 것을 이해하므로 전체 데이터 읽기 프로세스가 다릅니다. 여전히 이해가 되지 않습니다. 왜 /dev/sr0또는 의 일반 블록 장치처럼 읽을 수 없는가 /dev/cdrom? 일반 소프트웨어로는 블록 수준에서 읽을 수 없는 CDDA의 특별한 점은 무엇입니까?
내 말은 결국 그것은 단지 바이트 스트림이라는 뜻입니다. 블록 장치가 아니라면 문자 장치가 마음에 드는데 왜 dd// 다른 블록/문자 장치처럼 사용할 수 없습니까 cat? nbd실제적이고 기술적인 이유가 있습니까? 아니면 Linux에서 CDDA 매체에 대한 액세스를 구현하기 위한 합리적인 사용 사례를 아무도 찾지 못했기 때문입니까?
답변1
오디오 CD(또는CD-DA, 독점에 지정됨레드북)은 CD의 가장 오래된 형식입니다. 형식은 오디오 레코드에서 영감을 얻었으므로 연속 데이터가 있는 나선형 트랙이 있고 이 데이터와 인터리브된 것은 타이밍 정보입니다. 적절한 블록 헤더가 없습니다. 정보의 가장 작은 단위는 1프레임, 즉 1/75초이며, 이는 2352 데이터 바이트(2채널의 경우, 2샘플/바이트, 44.1kHz)를 포함합니다.
이는 2의 거듭제곱이 아니며 256이나 512로 나누지도 않습니다. 따라서 오디오 프레임을 데이터 블록으로 처리하는 것은 약간 어색합니다. 게다가 초기 CD 드라이브는 항상 올바른 위치에 있을 수 없기 때문에 "12분 4초 5 1/75초에 프레임을 읽어보세요"라고 말하면 때로는 몇 바이트 일찍 또는 늦게 시작될 수도 있습니다. 그렇기 때문에 오디오 CD(예: )를 "제대로" 읽을 수 있는 프로그램이 너무 많습니다 cdparanoia.
이제 이것을 데이터 CD(Yellow Book에 지정된 CD-ROM이라고도 함)와 대조해 보십시오. 그들은 오디오 프레임의 2352바이트를 가져와서 블록을 식별하기 위한 헤더 정보로 그 중 일부를 사용했습니다. 또한 또 다른 수준의 오류 수정 기능을 추가하여 오디오 프레임의 2352바이트가 데이터 프레임의 2048바이트가 되었습니다.
이제 블록 크기는 2의 거듭제곱이 있고, 적절한 헤더가 있고 정확한 검색을 수행할 수 있으며, 이것이 단지 블록 장치인 것처럼 가장할 수 있습니다.
따라서 기본적으로 오디오 CD는 블록 장치로 간주되지 않지만 데이터 CD는 블록 장치로 간주되는 이유가 바로 이것입니다.
즉, 오디오 CD의 정보를 각 트랙의 WAV 파일과 같이 파일 시스템에서 사용할 수 있도록 만들지 않을 이유가 없습니다. 실제로 다음과 같은 일부 오픈 소스 프로젝트가 있습니다.CDFS, 또는 FUSE를 사용하는 현재 기억이 나지 않는 다른 것들은 이런 방식으로 CD 데이터를 나타냅니다. 그러나 지터 보정 등이 없다는 문제가 여전히 남아 있으므로 cdparanoia.
그리고 커널 사람들도 그것이라고 생각했습니다.나쁜 생각.
답변2
오디오 CD용 CDDA는 CD-ROM용 파일 시스템(처음에는 High Sierra, 이후에는 ISO 9660)을 만들기 전에 만들어졌습니다. 그 전에는 CD가 일반 데이터 디스크처럼 작동하지 않았습니다. 그리고 그 후에도 오디오 CD는 여전히 기존 CD 플레이어와 역호환되어야 했기 때문에 변경할 수 없었습니다.