- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
void _debugPrintWaveHeader(const char *path, const WAVHEADER &source_header)
{
FILE *debug = fopen("path", "wt");
fprintf(debug, "chunkId = %s\n", source_header.chunkId);
fprintf(debug, "chunkSize = %u\n", source_header.chunkSize);
fprintf(debug, "format = %s\n", source_header.format);
fprintf(debug, "subCh1Id = %s\n", source_header.subchunk1Id);
fprintf(debug, "subCh1Size = %u\n", source_header.subchunk1Size);
fprintf(debug, "audioform = %u\n", source_header.audioFormat);
fprintf(debug, "numChanels = %u\n", source_header.numChannels);
fprintf(debug, "sampleRate = %u\n", source_header.sampleRate);
fprintf(debug, "byteRate = %u\n", source_header.byteRate);
fprintf(debug, "blockAlign = %u\n", source_header.blockAlign);
fprintf(debug, "bitsPerSam = %u\n", source_header.bitsPerSample);
fprintf(debug, "subCh2Id = %s\n", source_header.subchunk2Id);
fprintf(debug, "subCh2Size = %u\n", source_header.subchunk2Size);
fclose(debug);
}
Начал разгребать один говнопроект... При отладке программа всё падает и падает, падает и не может остановится. Смотрю на код - все в норме, а потом, по прошествии нескольких часов...
Follow us!
Так это просто опечатка, не говно. Ну ещё флажки в fprintf смущают (id строковые с явным size, но выводятся как zero-terminated строки).
> Как этот проект вообще работал ? =) Я только сегодня за него взялся, а уже 2 поста
Пф, иногда мне кажется, что говнокод это необходимое но недостаточное условие коммерческой успешности типичного проекта.
chunkId = RIFF¦d
chunkSize = 812198
format = WAVEfmt
subCh1Id = fmt
subCh1Size = 18
audioform = 1
numChanels = 1
sampleRate = 44100
byteRate = 44100
blockAlign = 1
bitsPerSam = 8
subCh2Id =
subCh2Size = 1686135156
Так еще неизвестно сколько еще там таких опечаток =)
Ну собственно о чем Роман выше и писал.
Во всяком случае, по выводу не похоже. Опять же, кто знает, какие типы у xxxSize, действительно ли там unsigned int :) Приличные компиляторы на такое ругаются.
format - тоже 4 байта ("WAVE"), а "fmt" в нем вылез от начала следующего чанка.
ReadWaveHeaderResult TMainForm::ReadWaveHeader(const wchar_t* filename, WAVHEADER &header)
{
FILE *file = _wfopen(filename, L"rb");
fread(&header, sizeof(WAVHEADER), 1, file);
fclose(file);
#if DEBUG_ON == 1
_debugPrintWaveHeader("C:\\logs\\open_wa ve_func.txt", header);
#endif
if(header.audioFormat != 1)
{
return ReadWaveHeaderResult::bad_audioFormat;
}
if(header.numChannels != 1)
{
return ReadWaveHeaderResult::bad_numChannels;
}
if(header.byteRate != 8 && header.byteRate != 16)
{
return ReadWaveHeaderResult::bad_byteRate;
}
return ReadWaveHeaderResult::good_result;
}
Это достойно отдельного поста да не хочу спамить =) (заспамлю ж все)
P.S. Хотя, конечно, проще бы прицепить либу и получать от нее готовые массивы семплов, и не трахаться с байтами и заголовками.
P.S. Ну еще ошибки открытия/чтеия не обработаны...
Бля, слона то я и не заметил ;)
P.S. А этот код вообще юзали? А то он, походу, совсем не рабочий.
Application->MessageBoxA(L"Количество бит на семпл олжно быть равно 8 или 16", L"Error", 0);
exit(0);
(Да, да - сообщение с опечаткой!)
Автор из пыхи с ее die(), видимо, пришел.
Пару watchdog'ов вполне решат проблему с крахами...
Ага, вместо фикса багов подопрём систему вотчдогами... Особенно круто это будет смотреться в GUI программе. Бедный юзер...
P.S. Против самих собачек ничего не имею, они полезны. Особенно на серверах и в embedded.
Был у меня на работе проектик с терминалами. И я там немного накосячил... В общем он крашился после каждой отрисовки экрана, переподключался к серверу, тот перевысылал ему состояние... Все дико мерцало, но можно было даже выбирать пункты в меню и т.п. Отказоустойчивость, мать её.
Автор не знал о модификаторе точности ;)
Писать свои велосипеды вместо встраиваемой СУБД?
Против великов для кастомного формата хранения я в общем-то против ничего не имею.
Ну просто, как я понимаю, они пытаются замутить ACID для таблички зависимостей. С той же berkeley db или sqlite это заняло бы от силы десяток строк. И сэкономило бы кучу времени на разработку/отладку...
Против кастомных форматов для хранения/транспорта я, конечно, ничего не имею. А вот когда этот формат начинает плавно обрастать атомарностью, конкурентностью, попытками спасти инфу после краша и т.п. - имхо, стоит задуматься.
Кстати, код по ссылке иногда сегфолтится (редко), но никто что-то не спешит разбираться, почему.
"Есть два метода создания программного обеспечения. Один из них — сделать программу настолько простой, что, очевидно, в ней нет недостатков. И другой, сделать приложение настолько сложным, что в нем не видно явных недостатков."
-- Энтони Хоар
> flush the file buffer after every record
Так что маловероятно... А если записи будут втыкаться не по одной, а пачками в транзакции (а они, походу, именно пачками и втыкаются) - то даже sqlite порвёт эту самоделку как тузик грелку.
Есть такое... Причем почему-то все думают, что "базы тормозят, бинарные файлы это круто", а сами начинают пилить свой WAL с блекджеком и flush'ами. Да что все, я и сам этим страдал...
// Set the buffer size to this and flush the file buffer after every record to make sure records aren't written partially.
// Check that the expected index matches the actual index. This can only happen if two ninja processes write to the same deps log concurrently
// An error occurred while loading; try to recover by truncating the file to the last fully-read record
Ну х.з., короче. До полного ACID'а оно еще не дотянуло. Но атомарность, согласованность и надежность уже начали прослеживаться...