Rst7

X.wav Y.wav

Если Вы возьмете кучу фотографий разных студий звукозаписи, то практически на 80% найдутся именно эти мониторы, а почти все они будут лежать вот в таком положении именно в таком месте пульта. Вы сейчас будете сильно смеяться, но именно в таком положении у них АЧХ ровнее. Именно конкретно у Yamaha NS-10m. Т.е. Вы тоже готовы отличить один .wav-файл от другого, да? Понятное дело, что ABX-тест более грамотен как методика. Но в данном случае - сложно реализуемо из-за "наличия отсутствия личного присутствия" ;) Потому два файла с безликими именами - наше все.

Зато это слово - первое по Вашей ссылке.

На фото ничего внутриканального нет. Но на нем есть стандартно применяющиеся в студиях референсные мониторы под названием Yamaha NS-10m. А по Вашей ссылке есть слово "референсный" (а слово "монитор" употребили Вы сами), но оно никакого отношения к музыкальному продакшну не имеет от слова совсем. Не применяют в этом деле наушники (особенно внутриканальные) кроме особых специфических случаев (мониторинг для самих музыкантов в процессе накопления в расчет не берем). 99% работы выполняется именно при помощи АС.

Я не очень-то вижу корреляцию между форматом сжатия и этой самой волной. Ну представьте себе ситуацию, что не было бы mp3. Все, что произошло, все равно произошло бы, просто позже, когда каналы/носители стали бы шире/объемнее. Как бы Вам так объяснить потактичнее. Референсы - вот, на фотографии, лежат боком на метербридже пульта, называются Yamaha NS-10m. На фотографии, кстати, одна из студий мастеринга на Abbey Road. А то, что написано на сайте по Вашей ссылке - это всего лишь продаванское обоснование, почему Вам надо лишний килобакс (или сколько там) заплатить. Вы хоть никому из профессиональных звукорежиссеров не скажите такую фразу, что "у меня референсные внутриканальные мониторы", засмеют ;)

"Внутриканальные мониторы" бывают у музыкантов на сцене, если что. А в применении к обычному прослушиванию музыки такой термин - не более чем пиар-ход от продаванов. Я Вам завтра на студии два .wav-файла сделаю. Один - оригинал, второй - после mp3. А Вы попробуете найти оригинал на слух.

Вот прям mp3 - корень всех зол. Скажите, лично Вы в двойном слепом тесте wav 16/44110 от mp3 320kbps отличаете?

А какое отношение имеют "большие динамики" к басу? Вон обычные 15тидюймовые горшки в концертных топах ниже 60-70Гц и не играют. А размером будь здоров. Вообще-то нижняя граничная частота АС не от размера динамика зависит. Для басов просто обклейка какими-нибудь моднейшими поролоновыми пирамидками ничего не изменит. Там совсем по другому ловушки басовые устроены. Да что Вы говорите? Это если бы не мастерили альбомы - тогда да. А так смысл современного мастеринга в том и заключается, чтобы привести, так сказать, к общему знаменателю например по АЧХ и громкости все треки альбома. Какие еще такие компрессоры? Вся компрессия в нужных количествах сделана звукорежиссером и мастеринг-инженером на постпродакшне. И поверьте, при более-менее вменяемой АЧХ связки АС+комната Вы никаких таких артефактов не услышите. Исключая, понятное дело, упоротых на голову любителей сделать финальный микс погромче, например, с RMS в -6дБ ;) Ох лол. Ставшие де-факто стандартом студийного мониторинга такие АС, как Yamaha NS-10m не отличаются линейной АЧХ. Так что "прослушивание на линейном тракте" - это отнюдь не совсем то, "что придумал записывающий звукорежиссер". Хорошо, что их с производства сняли, потому эра этих "прекрасных" мониторов потихоньку отходит в прошлое.

Moderator: Уважаемые, настоятельно призываю вернуть дискуссию в конструктивное русло. Иначе буду наказывать.

А вот это Вы неправы совершенно. Если бы Вы внимательно прочитали там где-то ближе к началу темы, как я рассказывал за изменение типа резонанса (с картинками измерений и прочим), то тогда бы поняли, что никакой аудиофилией тут и не пахнет, сугубо инженерный подход.

Из какой, простите? Аудиофильской в ругательном смысле?

Еще раз. а) Измеряем АЧХ по звуковому давлению при Rвых=0. б) Меняем Rвых=бесконечность. Результирующая АЧХ умножается на кривую импеданса (какой-то константный множитель, отвечающий за коэффициент преобразования напряжение/ток усилителя опускаем). Где импеданс выше (например, есть резонансный пик) - там АЧХ по звуковому давлению будет выше (как раз, как этот резонансный пик). А вот это, как говорится, не моя проблема. Не пользуйтесь ширпотребом. Смотрите внимательно, что именно Вы покупаете - смотрите схемотехнику, измеряйте сами параметры, проводите корреляции между тем, что слышите, и тем, что измеряете - в двойных слепых тестах, конечно. И главное - не приплетайте "неизвестных науке фактов". А иначе это все аудиофилия на всю голову.

Я не понимаю, что Вы смотрите. Все поля msg_p.p у Вас нулевые. Это неправильно. Кроме того, p->next валиден только для пустых элементов. Я же специально написал вменяемую функцию дампа этой базы в последнем примере: void DumpDatabase(void) { int i; printf("---- DB len=%d -----\n",glob_pos); for(i=0; i<glob_pos; i++) { printf("idx=%d id=%d data=%s\n",i,msg_p[i].id,msg_p[i].p->data); } } Что печатает эта функция в Вашем случае? p->next не должен там обновляться. Он всего лишь указывает на следующий элемент в очереди пустых (которая MsgFreeQ)! Когда элемент занят, то из очереди MsgFreeQ он исключен, и указатель на него хранится только в массиве msg_p, а указатель next невалиден, он заполнен данными data (там же специально union написан, а не struct, объединяющий next и data).

А Вы возьмите и сами перемеряйте. Будете сильно удивлены, насколько графики из интернетов не соответствуют реальной жизни. На пиках импеданса будет повышенный уровень звукового давления при Rвых>0. А не провал.

Я так за Вас всю работу сделаю. Вот код, проверенный на большом брате (кроме банальных описок ничего не исправлялось): //--------------------------------------------------------------------------- #include <stdio.h> #pragma hdrstop #include <tchar.h> //--------------------------------------------------------------------------- #define MESSAGE_ARR_SIZE 128 typedef struct TEST_MESSAGE { union { char data[20]; struct TEST_MESSAGE *next; }; }TEST_MESSAGE; typedef struct { int id; TEST_MESSAGE *p; }TEST_MESSAGE_P; TEST_MESSAGE *MsgFreeQ; TEST_MESSAGE messages[MESSAGE_ARR_SIZE]; TEST_MESSAGE_P msg_p[MESSAGE_ARR_SIZE]; int glob_pos; int BinarySearch(TEST_MESSAGE_P *a, int pos, int key) { int first = 0; int last = pos; int mid; if (pos == 0) //empty array { return ~0; } else if (a[0].id > key) { return ~0; } else if (a[pos - 1].id < key) { return ~pos; } while (first < last) { mid = first + (last - first) / 2; if (key <= a[mid].id) last = mid; else first = mid + 1; } if (a[last].id == key) { return last; } else { return ~last; } } TEST_MESSAGE *AllocMessage(void) { TEST_MESSAGE *p=MsgFreeQ; if (p) MsgFreeQ=p->next; return p; } void FreeMessage(TEST_MESSAGE *p) { p->next=MsgFreeQ; MsgFreeQ=p; } void InitMessageQ(void) { int i; for(i=0; i<MESSAGE_ARR_SIZE; i++) { FreeMessage(messages+i); } } void UpdateElement(TEST_MESSAGE *p, char msg[]) { memcpy(p->data,msg,sizeof(p->data)); } void InsertElement(int id, char msg[]) { int idx; idx = BinarySearch(msg_p, glob_pos, id); if (idx>=0) //command NEW but the element exists - issue UPDATE { UpdateElement(msg_p[idx].p, msg); //void UpdateElement(TEST_MESSAGE *p, char *inmsg) } else //element not found - add one { TEST_MESSAGE *nm=AllocMessage(); idx=~idx; if (!nm) nm=msg_p[MESSAGE_ARR_SIZE-1].p; //Если не удалось аллоцировать новый элемент - заменяем последний memmove(msg_p+(idx+1), msg_p+idx, sizeof(TEST_MESSAGE_P)*(glob_pos-idx)); msg_p[idx].id = id; msg_p[idx].p=nm; memcpy(nm->data, msg, sizeof(nm->data)); if (glob_pos < MESSAGE_ARR_SIZE) glob_pos++; } } void DeleteElement(int id) { int idx; idx = BinarySearch(msg_p, glob_pos, id); if (idx>=0) { FreeMessage(msg_p[idx].p); memmove(msg_p+idx, msg_p+(idx+1), sizeof(TEST_MESSAGE_P)*(glob_pos-idx)); if (glob_pos > 0) glob_pos--; } } void DumpDatabase(void) { int i; printf("---- DB len=%d -----\n",glob_pos); for(i=0; i<glob_pos; i++) { printf("idx=%d id=%d data=%s\n",i,msg_p[i].id,msg_p[i].p->data); } } #pragma argsused int _tmain(int argc, _TCHAR* argv[]) { InitMessageQ(); InsertElement(3,"3333"); DumpDatabase(); InsertElement(5,"5555"); DumpDatabase(); InsertElement(7,"7777"); DumpDatabase(); InsertElement(6,"6666"); DumpDatabase(); return 0; } //--------------------------------------------------------------------------- Выдача после работы функции main: ---- DB len=1 ----- idx=0 id=3 data=3333 ---- DB len=2 ----- idx=0 id=3 data=3333 idx=1 id=5 data=5555 ---- DB len=3 ----- idx=0 id=3 data=3333 idx=1 id=5 data=5555 idx=2 id=7 data=7777 ---- DB len=4 ----- idx=0 id=3 data=3333 idx=1 id=5 data=5555 idx=2 id=6 data=6666 idx=3 id=7 data=7777

Это как раз довольно большой КНИ во втором случае. Причем, основная проблема в том, что громкие звуки продуцируют много ВЧ-гармоник, которые маскируют тихие звуки в том же диапазоне (а все это железо шелестит выше 1кГц и до упора).

Осталось только решить, что такое детализация. Если это панорамирование инструментов влево/вправо - то связана очень опосредовано. Скажем, если инструмент спанорамирован больше в левый канал, то при наличии большого количества дополнительных гармоник в тракте он будет казаться еще левее. Да еще и при большом количестве гармоник окажется малость размазанным по панораме. Но эффект крайне мал при вменяемом для 21го века КНИ тракта. Я вообще сомневаюсь, что его можно услышать в полном миксе, а не выслушивая отдельный инструмент. А вот если говорить о расположении кажущегося источника звука ближе/дальше от слушателя - то связанна. Большой КНИ приводит к тому, что становятся плохо слышны реверберационные хвосты (или они сильно искажаются), а именно они ответственны за иллюзию дистанции до источника звука. Но именно этот момент в наушниках не работает, только при прослушивании через АС.

Ээээ, так у Вас массив пустой, который msg_p. Где-то потеряна запись в поле msg_p[xxx].p. Нет, конечно. Все должно быть так, как написано. Это же добыватель элемента из односвязного списка. Вы там, случайно, процедуру инициализации не забыли вызвать? И только один раз ее можно вызывать, если что.

Ну и чисто эстетический момент. Лично меня вымораживает возврат таких простых флагов через указатели на переменные. Куда оптимальнее выглядит все вот так: #define MESSAGE_ARR_SIZE 128 typedef struct TEST_MESSAGE { union { char data[20]; struct TEST_MESSAGE *next; }; }TEST_MESSAGE; typedef struct { int id; TEST_MESSAGE *p; }TEST_MESSAGE_P; TEST_MESSAGE *MsgFreeQ; TEST_MESSAGE messages[MESSAGE_ARR_SIZE]; TEST_MESSAGE_P msg_p[MESSAGE_ARR_SIZE]; int glob_pos; int BinarySearch(TEST_MESSAGE_P *a, int pos, int key) { int first = 0; int last = pos; int mid; if (pos == 0) //empty array { return ~0; } else if (a[0].id > key) { return ~0; } else if (a[pos - 1].id < key) { return ~pos; } while (first < last) { mid = first + (last - first) / 2; if (key <= a[mid].id) last = mid; else first = mid + 1; } if (a[last].id == key) { return last; } else { return ~last; } } TEST_MESSAGE *AllocMessage(void) { TEST_MESSAGE *p=MsgFreeQ; if (p) MsgFreeQ=p->next; return p; } void FreeMessage(TEST_MESSAGE *p) { p->next=MsgFreeQ; MsgFreeQ=p; } void InitMessageQ() { for(unsigned int i=0; i<MESSAGE_ARR_SIZE; i++) { FreeMessage(messages+i); } } void InsertElement(int id, char msg[]) { int idx; idx = BinarySearch(msg_p, glob_pos, id); if (idx>=0) //command NEW but the element exists - issue UPDATE { UpdateElement(msg_p[idx]->p, msg); //void UpdateElement(TEST_MESSAGE *p, char *inmsg) } else //element not found - add one { idx=~idx; TEST_MESSAGE *nm=AllocMessage(); if (!nm) nm=msg_p[MESSAGE_ARR_SIZE-1].p; //Если не удалось аллоцировать новый элемент - заменяем последний memmove(msg_p+(idx+1), msg_p+idx, sizeof(TEST_MESSAGE_P)*(glob_pos-1-idx)); msg_p[idx].id = id; msg_p[idx].p=nm; memcpy(nm->data, msg, sizeof(nm->data)); if (glob_pos < MESSAGE_ARR_SIZE) glob_pos++; } } void DeleteElement(int id) { int idx; idx = BinarySearch(msg_p, glob_pos, id); if (idx>=0) { FreeMessage(msg_p[idx]->p); memmove(msg_p+idx, msg_p+(idx+1), sizeof(TEST_MESSAGE_P)*(glob_pos-1-idx)); if (glob_pos > 0) glob_pos--; } } Что значит одно и то же? Копирование, скажем 128 элементов по 24 байта это медленнее, чем копирование 128 элементов по 8 байт? Или одно и то же? Очередь свободных элементов создана заранее, прямо на месте буфера данных. Аллоцирование и освобождение элемента занимает буквально несколько тактов, это же не malloc из библиотеки, посмотрите на функции, я же их написал.

Обновите страничку, в предыдущем посте я уже Вам код написал. На самом деле есть одно узкое место. Зависит от того, что Вам нужно делать при переполнении буфера пакетов. Я имею в виду функцию InsertElement. Возможно, она должна выглядеть чуть по другому void InsertElement(int id, char msg[]) { int idx; idx = BinarySearch(msg_p, glob_pos, id, &found); if (found) //command NEW but the element exists - issue UPDATE { UpdateElement(idx, msg); } else //element not found - add one { TEST_MESSAGE *nm=AllocMessage(); if (!nm) nm=msg_p[MESSAGE_ARR_SIZE-1].p; //Если не удалось аллоцировать новый элемент - заменяем последний memmove(msg_p+(idx+1), msg_p+idx, sizeof(TEST_MESSAGE_P)*(glob_pos-1-idx)); msg_p[idx].id = id; msg_p[idx].p=nm; memcpy(nm->data, msg, sizeof(nm->data)); if (glob_pos < MESSAGE_ARR_SIZE) glob_pos++; } }

Вы переносите структуру размером int+char[20], что для 32хбитной архитектуры будет 24 байта. И таких может быть аж столько, сколько размер массива. На самом деле надо переносить структуру int+pkt*, что есть всего 8 байт, в 3 раза меньше. Но для этого еще надо организовать очередь пустых элементов (для добавления нового/удаления). Очередь эту вполне можно организовать прямо на месте тел сообщений. Должно быть как-то так #define MESSAGE_ARR_SIZE 128 typedef struct TEST_MESSAGE { union { char data[20]; struct TEST_MESSAGE *next; }; }TEST_MESSAGE; typedef struct { int id; TEST_MESSAGE *p; }TEST_MESSAGE_P; TEST_MESSAGE *MsgFreeQ; TEST_MESSAGE messages[MESSAGE_ARR_SIZE]; TEST_MESSAGE_P msg_p[MESSAGE_ARR_SIZE]; int found; int glob_pos; int BinarySearch(TEST_MESSAGE_P *a, int pos, int key, int *found) { int first = 0; int last = pos; int mid; if (pos == 0) //empty array { *found = 0; return 0; } else if (a[0].id > key) { *found = 0; return 0; } else if (a[pos - 1].id < key) { *found = 0; return pos; } while (first < last) { mid = first + (last - first) / 2; if (key <= a[mid].id) last = mid; else first = mid + 1; } if (a[last].id == key) { *found = 1; return last; } else { *found = 0; return last; } } TEST_MESSAGE *AllocMessage(void) { TEST_MESSAGE *p=MsgFreeQ; if (p) MsgFreeQ=p->next; return p; } void FreeMessage(TEST_MESSAGE *p) { p->next=MsgFreeQ; MsgFreeQ=p; } void InitMessageQ() { for(unsigned int i=0; i<MESSAGE_ARR_SIZE; i++) { FreeMessage(messages+i); } } void InsertElement(int id, char msg[]) { int idx; idx = BinarySearch(msg_p, glob_pos, id, &found); if (found) //command NEW but the element exists - issue UPDATE { UpdateElement(idx, msg); } else //element not found - add one { TEST_MESSAGE *nm=AllocMessage(); if (nm) { memmove(msg_p+(idx+1), msg_p+idx, sizeof(TEST_MESSAGE_P)*(glob_pos-1-idx)); msg_p[idx].id = id; msg_p[idx].p=nm; memcpy(nm->data, msg, sizeof(nm->data)); if (glob_pos < MESSAGE_ARR_SIZE) glob_pos++; } } } void DeleteElement(int id) { int idx; idx = BinarySearch(msg_p, glob_pos, id, &found); if (found) { FreeMessage(msg_p[idx]->p); memmove(msg_p+idx, msg_p+(idx+1), sizeof(TEST_MESSAGE_P)*(glob_pos-1-idx)); if (glob_pos > 0) glob_pos--; } } Обратите внимание, что есть процедура InitMessageQ, ее надо вызвать в самом начале.

Ну правильно вот так memcpy(messages[idx].data, msg, sizeof(messages[0].data)); Но все же, это все не совсем то, о чем говорили все предыдущие посты. Вы носите весь массив вместе с данными для вставки/удаления, а надо только указатели.

Что значит не будет? Вы бы почитали про адресную арифметику в Си, для начала. &(a[2])==a+2, если что.

Нет. Надо так memmove( a+(i+1), a+i, sizeof(A)*(N-1-i));

Алдошина. Ну та еще дьяволица, надо сказать. Писать пространные тексты в том числе на звукорежиссерскую тематику, не имея ни одного релиза на вменяемых зарубежных лейблах - это да, показатель. Естественно. Вверху - упираются в границы линейности упругие элементы, внизу - гистерезис в тех же элементах. А в середине диапазона все вполне терпимо. Ага, могу привести цитату из другого места, где она говорит про то, что неравномерность ГВЗ в звуковом диапазоне порядка пары миллисекунд не слышна. Оценить сколько кругов фаза наматывает за миллисекунду при частотах в килогерцы можете сами. Не было такой фразы у меня. Вам надо отвыкнуть от принципиально кривых АЧХ внутриканальных наушников и послушать музыку в более адекватных условиях, не нарушая собственные резонансы ушей. Потом возвращаться к внутриканальным.