Как считать данные с музыкального диска (Audio-CD),
То-бишь типа Audio grabber?????
Подскажите хотя-бы в каком направлении мне двигатся,
через какие ф-ции.
Самый простой способ — использовать ASPI. Подробнее — поиском на группо-гугле
С>Как считать данные с музыкального диска (Audio-CD), С>То-бишь типа Audio grabber????? С>Подскажите хотя-бы в каком направлении мне двигатся, С>через какие ф-ции.
А этот способ еще проще.. но только под семейством NT
1. Obtain a handle to the CD device using the name "\\.\E:"
DeviceHandle = CreateFile (DosDeviceName,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
0,
NULL);
2. Allocate an aligned I/O buffer. (It isn't clear if this is really
needed, but I figured it couldn't hurt.)
AlignedBuffer = VirtualAlloc (NULL,
BytesToRead * 2,
MEM_COMMIT,
PAGE_READWRITE);
Oh yes. The number of bytes being read is 2352. (The raw sector
size.) I allocated double the size, just to be sure.
3. Finally, do the actual read.
ReadInfo.DiskOffset.LowPart = 0;
ReadInfo.DiskOffset.HighPart = 0;
ReadInfo.SectorCount = 1;
ReadInfo.TrackMode = CDDA;
BytesRead = 0;
Status = DeviceIoControl (DeviceHandle,
IOCTL_CDROM_RAW_READ,
&ReadInfo, //SystemBuffersizeof (RAW_READ_INFO), //InputBufferLength
AlignedBuffer,
BytesToRead, //OutputBufferLength
&BytesRead, //Information
NULL);
Здравствуйте, Andrew S, Вы писали:
AS>Самый простой способ — использовать ASPI. Подробнее — поиском на группо-гугле
С>>Как считать данные с музыкального диска (Audio-CD), С>>То-бишь типа Audio grabber????? С>>Подскажите хотя-бы в каком направлении мне двигатся, С>>через какие ф-ции.
Например:
Я считываю первый сектор, ставлю
ReadInfo.DiskOffset.LowPart = 0;
Считывается 2352 байт.
Но следующий начинается не с 2352 а с 2048. т.е.
ReadInfo.DiskOffset.LowPart = 2048; потом
ReadInfo.DiskOffset.LowPart = 4096; и т.д.
Почему?
Где бы про это узнать.
Еще в MSDN описаны другие IOCTL но в header'ах (DDK&SDK) я их не нашел...
пр:
IOCTL_CDROM_READ_TOC_EX
CDROM_READ_TOC_EX_FORMAT_TOC
CDROM_READ_TOC_EX_FORMAT_CDTEXT
...
По старинным преданиям... На самом деле по моим воспоминаниям об MSCDEX есть 2 (по крайней мере) режима raw чтения данных с компакт диска.
1 cooked — подготовленый, читает именно 2048 байт.
2 raw — читает все что есть eq полный сектор. На большинстве CD это 2352 байта.
В данном случае используется RAW режим. Возможно, твой CD не поддерживает raw? CD грабберы работают?
С>Но следующий начинается не с 2352 а с 2048. т.е. С>ReadInfo.DiskOffset.LowPart = 2048; потом С>ReadInfo.DiskOffset.LowPart = 4096; и т.д. С>Почему? С>Где бы про это узнать.
Узнать про это и многое другое можно в поиске по конференциям в группо-гугле
AS>По старинным преданиям... На самом деле по моим воспоминаниям об MSCDEX есть 2 (по крайней мере) режима raw чтения данных с компакт диска. AS>1 cooked — подготовленый, читает именно 2048 байт. AS>2 raw — читает все что есть eq полный сектор. На большинстве CD это 2352 байта.
AS>В данном случае используется RAW режим. Возможно, твой CD не поддерживает raw? CD грабберы работают?
Ну-с, начнем-с о моих исследованиях....
У меня CDR — Teac, CDRW — NEC
Оба прекрасно грабят....
Насколько я правильно выяснил У CD-ROM'ов
размер сектора равен 2048, поэтому при адресации
используется это число...
0, 2048, 4096,...
0, 1, 2...
Но, как я правильно понял:
Указатели на трэки используются по формуле:
M — min, S — sec, F — frames
Offset(Track) = ((M * 60) + (S — 2) * 75) + F
Кстати, я 2 сек отнимал — тогда все трэки вставали на свои
места(не с'езжали). У меня диск есть на к-ром без пауз трэки записаны —
на нем и тестировал....
Предположим, что
Размер 1 секунды в RAW = 2 * 2 (Channel) * 44100 (Hz) = 176400 байт
Я написал сначала на C кусочек — все заработало,
потом небольшую программку на Delphi (ну нравится мне на нем писать
к-рая с диска считывает toc (инфу о трэках) и сразу в mp3 гонит.
Все заработало как часы. Пару дисков на радостях опробовал....
Но под утро вырубили свет, и тут начались проблемы...
Ни на дельфи ни на С теперь не выполняется read RAW.
Погрешил на срухнувшие драйвера — опробовал на дву других
машинах (XP) — такая-же фигня, просто аномалия какая-то.....
Другие проги грабят по прежнему — все Ок!
Так, что писать надо через ASPI (где-то я его под NT скачал)
или (если я правильно понял) SPTI...
Мож кто быстрые ссылки подскажет или раскажет... образно ?
Скажу честно с английским тяжело, но стараюсь справляться....
По поводу моих догадок с секторами...
Сильно не смейтесь, если я чушь здесь несу, поправте....
Здравствуйте, Станислав, Вы писали:
AS>>По старинным преданиям... На самом деле по моим воспоминаниям об MSCDEX есть 2 (по крайней мере) режима raw чтения данных с компакт диска. AS>>1 cooked — подготовленый, читает именно 2048 байт. AS>>2 raw — читает все что есть eq полный сектор. На большинстве CD это 2352 байта.
AS>>В данном случае используется RAW режим. Возможно, твой CD не поддерживает raw? CD грабберы работают?
Все зависит от.
A CD logical sector size is 2048, 2052, 2056, 2324, 2332, 2336, 2340 or 2352 bytes per sector. These values correspond
to the user data plus various configurations of header, subheader and EDC/ECC.
Размер "чистых данных" (все что минус "various configurations of header, subheader...") зависит от режима
1. Yellow Book Mode 1 — 2048
2. Yellow Book Mode 2 — 2336
3. XA Mode Form 1 — 2048
4. XA Mode Form 2 — 2324
5. CDDA — 98 Small Frame
The physical format of CD-ROM and CD-DA media uses a smaller unit of synchronization than the more familiar
magnetic or optical recording systems. The basic data stream synchronization unit is a small frame. This is not the same
large frame (sector) as referred to in the MSF unit. Each small frame consists of 588 bits. A sector on CD media consists
of 98 small frames.
A CD small frame consists of:
1. 1 synchronization pattern (24+3 bits)
2. 1 byte of sub-channel data (14+3 bits)
3. 24 bytes of data (24 x (14+3) bits)
4. 8 bytes of CIRC code (8 x (14+3) bits) Total: 588 bits.
Data, sub-channel and CIRC bytes are encoded with an 8-bit to 14-bit code; then three merging bits are added. The
merging bits are chosen to provide minimum low-frequency signal content and optimize phase lock loop performance.
Frame Format for Audio
Each small frame of an audio Track on a two-channel CD-DA or CD-ROM media consists of six digitized 16-bit samples
of each audio channel. These 24 bytes of data are combined with a synchronization pattern, CIRC bytes and a subchannel
byte to make a frame. Each frame takes approximately 136.05 µs to play. This gives a sampling rate of 44.1 kHz
for each channel. The sub-channel information creates the higher level sector grouping for audio Tracks.
Итак, в случае CDDA получаем 588*98/8 = 7203 байта. Да ну....
Я точно помню в MSCDEX Там говорилось, что размер сектора raw CDDA составляет 2352 байта. И сейчас ищу по гуглю — везде про 2352 байта речь. Странно. Зато вот 2352 делится на 98. При этом получается 24. Итого — правильно, ровно чистные данные.
Здравствуйте, Andrew S, Вы писали:
AS>Итак, в случае CDDA получаем 588*98/8 = 7203 байта. Да ну.... AS>Я точно помню в MSCDEX Там говорилось, что размер сектора raw CDDA составляет 2352 байта. И сейчас ищу по гуглю — везде про 2352 байта речь. Странно. Зато вот 2352 делится на 98. При этом получается 24. Итого — правильно, ровно чистные данные.
Здравствуйте, Andrew S, Вы писали:
AS>Так именно. Именно поэтому и сомневаюсь. Слишком большой оверхед. 7203 и из них только 2352 данных.
А ты не сумлевайся. Сие взято из INF-8090i Rev 5.1 — "SFF Committee Information Specification for ATAPI DVD Devices". Впрочем в ECMA-130 — "Data interchange on read-only 120 mm optical data disks" написано то же самое.
T10/1363-D — "SCSI Multimedia Commands – 3" глаголет:
Data is recorded in a continuous stream of Small Frames. Each byte of a Small Frame is encoded with an 8 bit
to 14 bit modulation (EFM) code. Three merging bits are appended. The merging bits are chosen to provide
minimum low-frequency signal content and optimize phase lock loop performance. Each Small Frame consists
of 588 EFM bits
A CD frame consists of 98 contiguous Small Frames. This yields 24*98 = 2352 bytes of main channel data per
frame and 98 bytes of Sub-channel data per CD frame. A recorded CD is a succession of CD frames. For
audio, the bounds of a CD frame are defined by the Sub-channel bytes and for data, are determined by the
sync bytes in the main channel data.
Ага. Тогда считаем размер сектора так: 98*(588/14) = 98*42 = 4416 Этому уже поверить можно. Но все равно- оверхед великоват.
А вообще — в гугле все говорят про 2352 байта при чтении CreateFile'ом. Видимо, драйвер самолично вырезает main stream из потока.
Здравствуйте, Andrew S, Вы писали:
AS>Ага. Тогда считаем размер сектора так: 98*(588/14) = 98*42 = 4416 Этому уже поверить можно. Но все равно- оверхед великоват. AS>А вообще — в гугле все говорят про 2352 байта при чтении CreateFile'ом. Видимо, драйвер самолично вырезает main stream из потока.
Ну, ето можно увидеть невооруженным глазом, посмотрев в DDK на storage\filters\cdaudio. А вообще, чтоб у сидюка забрать что-то большее чем ети 2352 нужно сильно постараться.
Почетный кавалер ордена Совка.
Re[13]: ASPI: Как считать данные с музыкального диска?
P>Ну, ето можно увидеть невооруженным глазом, посмотрев в DDK на storage\filters\cdaudio. А вообще, чтоб у сидюка забрать что-то большее чем ети 2352 нужно сильно постараться.
Ну с секторами вроде все понятно. Достаточно было скачать спецификацию....
Помогите мне пожайлуста вот с каким вопросом:
Каким образом, посредством ASPI, Достать CD-TEXT.
Это название трэков на CDDA.
Все, что я выяснил это то, что инфа эта находится в lead-in
в sub-channels. И чтоб прочитать их нужно считать диск с адреса
(LBA) $F0000000, Но что-то у меня ничего не выходит...
У меня стоят XP с Adaptec's ASPI драйвером.
Диски грабит на ура... Все работает. Как бы текст вытащить ????
Re[14]: ASPI: Как считать данные с музыкального диска?
[]
С>Помогите мне пожайлуста вот с каким вопросом:
С>Каким образом, посредством ASPI, Достать CD-TEXT. С>Это название трэков на CDDA.
С>Все, что я выяснил это то, что инфа эта находится в lead-in С>в sub-channels. И чтоб прочитать их нужно считать диск с адреса С>(LBA) $F0000000, Но что-то у меня ничего не выходит...
Чезтно говоря ни разу не пробовал, и дисков у мине таких нет...
Хотя, на вскидку:
1. Проверить MODE SENCE'ом бит
R-W in Lead-in Readable This bit indicates that the Logical Unit is capable of reading R-W subcode in the
Lead-in. This is used with CD-Text.
сие находиться в C/DVD Capabilities and Mechanical Status Page Format (2Ah)2. Ежели он установлен, то READ TOC/PMA/ATIP с Format = 0x05 (This format returns CD-Text information from the Lead-in)
Здравствуйте, Станислав, Вы писали:
С>Я написал сначала на C кусочек — все заработало, С>потом небольшую программку на Delphi (ну нравится мне на нем писать С>к-рая с диска считывает toc (инфу о трэках) и сразу в mp3 гонит. С>Все заработало как часы. Пару дисков на радостях опробовал....
У меня с граббилкой следующая проблема. Надо грабить и под NT и под Win9x. По NT все понятно: через DeviceIoControl все заработало. Под 98 не работает. Может посоветуете чего?..
Здравствуйте, Motek, Вы писали:
M> У меня с граббилкой следующая проблема. Надо грабить и под NT и под Win9x. По NT все понятно: через DeviceIoControl все заработало. Под 98 не работает. Может посоветуете чего?..
Вот некоторые куски... Думаю, теорию поймешь,
Для корректной работы под NT пиши чкркз SPTI:
function sptiReadTOC(Var CdRom: TCdRom): Boolean;
var
hDrive : LongWord;
dwFlags : LongWord;
dwReturned : LongWord;
length : LongWord;
swb : SCSI_PASS_THROUGH_DIRECT_WITH_BUFFER;
SRBToc : TSRBToc;
i : Integer;
pd : TPackData;
begin
dwFlags := GENERIC_READ;
Result := False;
if getOsVersion >= OS_WIN2K then
dwFlags := dwFlags or GENERIC_WRITE;
hDrive := CreateFile(PChar(Format('\\.\%s:', [CdRom.DriveLetter])),
dwFlags, FILE_SHARE_READ, nil, OPEN_EXISTING, 0, 0);
if hDrive = INVALID_HANDLE_VALUE then Exit;
// It seems that with no Administrator privileges the handle value will be invalid
dwReturned := 0;
length := sizeof(SCSI_PASS_THROUGH_DIRECT_WITH_BUFFER);
ZeroMemory(@swb, sizeof(swb));
swb.spt.Length := sizeof(SCSI_PASS_THROUGH);
swb.spt.CdbLength := 10;
swb.spt.DataIn := SCSI_IOCTL_DATA_IN;
swb.spt.DataTransferLength := sizeof(TSRBToc);
swb.spt.TimeOutValue := 5;
swb.spt.DataBuffer := @SRBToc;
swb.spt.SenseInfoOffset := SizeOf(swb.spt) + SizeOf(swb.Filler);
swb.spt.Cdb[0] := $43; // read TOC
swb.spt.Cdb[1] := $02; // MSF mode
swb.spt.Cdb[7] := Hi(swb.spt.DataTransferLength);
swb.spt.Cdb[8] := Lo(swb.spt.DataTransferLength);
Result := DeviceIoControl(hDrive, IOCTL_SCSI_PASS_THROUGH_DIRECT,
@swb, length, @swb, length, dwReturned, nil);
CloseHandle(hDrive);
end;
Под Win 98 ASPI:
ASPIdll = 'wnaspi32.dll';
initialization
ASPI_HInst := LoadLibrary(PChar(ASPIdll));
if ASPI_HInst <> 0 then
begin
@SendASPI32Command := GetProcAddress(ASPI_HInst, 'SendASPI32Command');
@GetASPI32SupportInfo := GetProcAddress(ASPI_HInst, 'GetASPI32SupportInfo');
If Assigned(SendASPI32Command) And Assigned(GetASPI32SupportInfo) Then
ASPI_Loaded := True;
AspiInstalled := HIBYTE(LOWORD(GetASPI32SupportInfo)) = SS_COMP;
end;
finalization
if ASPI_Loaded then
begin
ASPI_Loaded := FreeLibrary(ASPI_HInst);
ASPI_HInst := 0;
@SendASPI32Command := nil;
@GetASPI32SupportInfo := nil;
end;
function aspiReadTOC(Var CdRom: TCdRom): Boolean;
var
ExecCmd : SRB_ExecSCSICmd;
hEvent : THandle;
i : Integer;
SRB : TSRBToc;
pd : TPackData;
begin
With CdRom.TocDesc do
begin
First := 0;
Last := 0;
SetLength(Toc, 0);
end;
Result := False;
If Not ASPI_Loaded Then Exit;
ZeroMemory(@SRB, SizeOf(SRB));
ZeroMemory(@ExecCmd, SizeOf(ExecCmd));
hEvent := CreateEvent(nil, TRUE, FALSE, nil);
ResetEvent(hEvent);
ExecCmd.SRB_Cmd := SC_EXEC_SCSI_CMD;
ExecCmd.SRB_HaId := CdRom.HaId;
ExecCmd.SRB_Target := CdRom.Target;
ExecCmd.SRB_Lun := CdRom.Lun;
ExecCmd.SRB_Flags := SRB_DIR_IN or SRB_EVENT_NOTIFY;
ExecCmd.SRB_BufLen := SizeOf(SRB);
ExecCmd.SRB_BufPointer := @SRB;
ExecCmd.SRB_SenseLen := SENSE_LEN;
ExecCmd.SRB_CDBLen := 10;
ExecCmd.SRB_PostProc := Pointer(hEvent);
ExecCmd.CDBByte[0] := $43; // read TOC
ExecCmd.CDBByte[1] := 2;
ExecCmd.CDBByte[2] := 0;
ExecCmd.CDBByte[9] := 0;
ExecCmd.CDBByte[6] := 0;
ExecCmd.CDBByte[7] := Hi(ExecCmd.SRB_BufLen);
ExecCmd.CDBByte[8] := Lo(ExecCmd.SRB_BufLen);
If SendASPI32Command(@ExecCmd) = HASTAT_OK Then
...
CloseHandle(hEvent);
end;
Здравствуйте, Станислав, Вы писали:
С>Здравствуйте, Motek, Вы писали:
M>> У меня с граббилкой следующая проблема. Надо грабить и под NT и под Win9x. По NT все понятно: через DeviceIoControl все заработало. Под 98 не работает. Может посоветуете чего?..
С>Вот некоторые куски... Думаю, теорию поймешь,
С>Для корректной работы под NT пиши чкркз SPTI:
Спасибо!
Где взять нормально написаные доки по SPTI и ASPI?
А не подскажешь, как это сделать через DeviceIoControl? А то мы под XP пишем и ASPI ой...
С>>Помогите мне пожайлуста вот с каким вопросом:
С>>Каким образом, посредством ASPI, Достать CD-TEXT. С>>Это название трэков на CDDA.
С>>Все, что я выяснил это то, что инфа эта находится в lead-in С>>в sub-channels. И чтоб прочитать их нужно считать диск с адреса С>>(LBA) $F0000000, Но что-то у меня ничего не выходит...
P>Чезтно говоря ни разу не пробовал, и дисков у мине таких нет... P>Хотя, на вскидку: P>1. Проверить MODE SENCE'ом бит P>
P>R-W in Lead-in Readable This bit indicates that the Logical Unit is capable of reading R-W subcode in the
P>Lead-in. This is used with CD-Text.
P>сие находиться в C/DVD Capabilities and Mechanical Status Page Format (2Ah)2. Ежели он установлен, то READ TOC/PMA/ATIP с Format = 0x05 (This format returns CD-Text information from the Lead-in)
[skipped]
P>ExecSCSICmd(&scmd); P>[/ccode]
Re[16]: ASPI: Как считать данные с музыкального диска?
?
