Я подумал, что всё чересчур непонятно описал, и потому ни одного ответа в результате не получил. Посему решил чуть поправить сие сообщение.....
Честно говоря все последние утверждения о том, что один редактор сводить умеет, другой нет мне немножка надоели... Так в чём собственно различие-то? Почему оно есть? Давайте разбираться.
Чисто теоретически:
сначала целочисленый сигнал (будь то 16 битный или какой другой - т.е. сигнал, представленный последовательностью целых чисел в интервале от (-2^N) до (2^N) - 1, где N = число битов пополам, т.е. равно 8 для 16-битного сигнала) переводится в 32-битный вещественный, с плавающей, понимаешь, точкой/запятой (кого как больше торкнет, судя повсему
).
На этой стадии могут возникнуть такие проблемы, как, например, число 8 перейдёт (ну условно разумеется, не обязательно именно 8, но какие-то числа - именно так и перейдут) в 7.99997 или в 8.00001 ну и т п. Собственно редактор никакой пока не виноват - таковО уж представление флоатовое, т.е. так "криво" в компьютере представляются вещественные числа, т.е. все те числа, которые лежат между целыми и которых бесконечно много, причём настолько бесконечно, что несчётно
. Разумеется мы, люди, не пишем в обычной жизни 8,0000000.... (или 7.9999999... - эти числа равны - разумеется при условии, что у 7-ки - бесконечное число 9-к),а пишем просто 8. А компьютор говорит, что либо мы пишем 8, тогда следующее число будет 9, либо мы пишем 8.0000000000001, а следующее число может быть уже 8.0000000000014, а число 8.0000000000000 мы представить совсем не можем. Почему? Ну давайте мы пока не будем вдаваться в то, как представляется веществ число в компьютере, главное это понять, что точных целых чисел может и не быть при таком представлении.
Теперь представим, что будет происходить со всеми нашими уже "вещественными" сигналами. Под сигналом я понимаю аудиодорожку. Итак допустим у нас 2 аудиодорожки и нужно провести их сведение - проще говоря сложить.
Вот здесь начинаются сложности. Во-первых, помимо сложения можно провести некоторую предвариетльную обработку этих сигналов какими-то плаг-инами и получить совсем не целые числа (здесь под целыми понимается не 8, 9 или -3, а вещественное их представление, т.е. те числа которые мы получили на первом шаге, например 8.000002, 9.000000 и -2.9999998), а что-нить вроде 7.546672 и т п... как это число потом обратно в инт преобразовывать (инт от int, которое от integer - целое. В языках программирования C/C++ используется для обозначения целых переменных. Например строчка int x; описывает переменную x целого типа). Терять всё, что стояло после запятой как-то обидно... Тогда и смысла-то к флоатам переходит особого не было.
Может случиться так, что пара сэмплов (имеется в виду не сэмпл с точки зрения какой-нить ГигаСтудии, а сэмпла - как элементарного значения сигнала в некоторый момент времени. Каждый вав-файл - последовательность сэмплов. Чем выше частота сэмплирования/дискретизации, тем больше сэмплов нужно для звука одинаковой во времени длины, т.е. тем чаще во времени мы считываем значение аналогового сигнала при оцифровке) улетит куда-нить в 1230000000000 (флоаты легко позволят такому числу быть представленным в компьютере, инты - нет - 2^32 - это всего 4 миллиарда с хвостиком, а у нас сигналы в лучшем случае 2^12 для 24-битного - в 12-й степени,а не в 24-й потому что половина всех чисел положительная, а вторая половина - отрицательная) - такое может возникнуть при делении на оч маленькое число - мало ли что у нас там плаг-ин делает - всё может быть, а при этом основной сигнал (т.е. большая часть всех сэмплов) будет иметь значения в интервале от -1000 до 1000 (ну условно - главное чтоб разница между пиками была значительная)?
Ну и как это должен обрабатывать редактор при обратном преобразовании в целые числа - звуковые карты ведь умеют работать только с целыми числами? Непонятно. Обрезать вылетающие пики и получить клиппирование? Или посчитать их за максимум, а из всего остального сигнала по сути получить тихий шум...Последнее выглядит значительно более бредово, однако тогда редактор должен как-то уметь определять основной диапазон сигнала, в нужных местах лимитируя его 0дБ, и более того, должен уметь маппировать (строить отображение одного множоество на другое) на инты максимально хорошо - так, чтобы "промежуточные между целыми" значения не потерялись. Т.е. например, чтобы 7.00001 перешло в 14, 7.52337 - перешло в 15, а 7.9988999 перешло в 16. При этом надо вместится в `16-24` бита звуковой карты.
При всей сложности вопроса, я тем не менее не думаю, что алгоритмы разных редакторов принципиально разные. Скорее всего все различия происходят в
1) клиппировании лимитированного сигнала - например сонар может просто обрезать, а куба - обрезать мягче (т.е. чуть скруглить сигнал в окрестностях пика так, чтоб он был нерезкий), однако такая проблема элементарно решается любым пик-лимитером.
2) Не стоит забывать и про дизеринг - здесь он тоже понадобится, хотя скорее из-за того, чтобы сгладить накапливающуюся составляющую ошибку округления, возникающей при работе с "плавающими" числами. В этом отноншении Сонар опять же имеет свой дизер, но управлять им мона на вкл/выкл. В то время как тот же куб имеет внешний управляемый дизер. Хорошо это или плохо - хороший вопрос и дать на него сразу ответ, что куба или лоджик или сонар или самплитуда или кто угодно рулит - опять же бредово. Мало ли например как там заоптимизирован дизер в сонаре под его движок - непонятно. Результат кстати он даёт ИМХО очень неплохой при его включении.
Так что если я в чём-то неправ. Поправляйте меня. Буду рад выдержать здоровую критику с тем, чтобы окончательно разобраться сколько травки кладут в компакт-диски с кубой или другими редакторами. А может у них интерфейс помигивает 25-м кадром Вот.
Честно говоря все последние утверждения о том, что один редактор сводить умеет, другой нет мне немножка надоели... Так в чём собственно различие-то? Почему оно есть? Давайте разбираться.
Чисто теоретически:
сначала целочисленый сигнал (будь то 16 битный или какой другой - т.е. сигнал, представленный последовательностью целых чисел в интервале от (-2^N) до (2^N) - 1, где N = число битов пополам, т.е. равно 8 для 16-битного сигнала) переводится в 32-битный вещественный, с плавающей, понимаешь, точкой/запятой (кого как больше торкнет, судя повсему
).На этой стадии могут возникнуть такие проблемы, как, например, число 8 перейдёт (ну условно разумеется, не обязательно именно 8, но какие-то числа - именно так и перейдут) в 7.99997 или в 8.00001 ну и т п. Собственно редактор никакой пока не виноват - таковО уж представление флоатовое, т.е. так "криво" в компьютере представляются вещественные числа, т.е. все те числа, которые лежат между целыми и которых бесконечно много, причём настолько бесконечно, что несчётно
. Разумеется мы, люди, не пишем в обычной жизни 8,0000000.... (или 7.9999999... - эти числа равны - разумеется при условии, что у 7-ки - бесконечное число 9-к),а пишем просто 8. А компьютор говорит, что либо мы пишем 8, тогда следующее число будет 9, либо мы пишем 8.0000000000001, а следующее число может быть уже 8.0000000000014, а число 8.0000000000000 мы представить совсем не можем. Почему? Ну давайте мы пока не будем вдаваться в то, как представляется веществ число в компьютере, главное это понять, что точных целых чисел может и не быть при таком представлении.Теперь представим, что будет происходить со всеми нашими уже "вещественными" сигналами. Под сигналом я понимаю аудиодорожку. Итак допустим у нас 2 аудиодорожки и нужно провести их сведение - проще говоря сложить.
Вот здесь начинаются сложности. Во-первых, помимо сложения можно провести некоторую предвариетльную обработку этих сигналов какими-то плаг-инами и получить совсем не целые числа (здесь под целыми понимается не 8, 9 или -3, а вещественное их представление, т.е. те числа которые мы получили на первом шаге, например 8.000002, 9.000000 и -2.9999998), а что-нить вроде 7.546672 и т п... как это число потом обратно в инт преобразовывать (инт от int, которое от integer - целое. В языках программирования C/C++ используется для обозначения целых переменных. Например строчка int x; описывает переменную x целого типа). Терять всё, что стояло после запятой как-то обидно... Тогда и смысла-то к флоатам переходит особого не было.
Может случиться так, что пара сэмплов (имеется в виду не сэмпл с точки зрения какой-нить ГигаСтудии, а сэмпла - как элементарного значения сигнала в некоторый момент времени. Каждый вав-файл - последовательность сэмплов. Чем выше частота сэмплирования/дискретизации, тем больше сэмплов нужно для звука одинаковой во времени длины, т.е. тем чаще во времени мы считываем значение аналогового сигнала при оцифровке) улетит куда-нить в 1230000000000 (флоаты легко позволят такому числу быть представленным в компьютере, инты - нет - 2^32 - это всего 4 миллиарда с хвостиком, а у нас сигналы в лучшем случае 2^12 для 24-битного - в 12-й степени,а не в 24-й потому что половина всех чисел положительная, а вторая половина - отрицательная) - такое может возникнуть при делении на оч маленькое число - мало ли что у нас там плаг-ин делает - всё может быть, а при этом основной сигнал (т.е. большая часть всех сэмплов) будет иметь значения в интервале от -1000 до 1000 (ну условно - главное чтоб разница между пиками была значительная)?
Ну и как это должен обрабатывать редактор при обратном преобразовании в целые числа - звуковые карты ведь умеют работать только с целыми числами? Непонятно. Обрезать вылетающие пики и получить клиппирование? Или посчитать их за максимум, а из всего остального сигнала по сути получить тихий шум...Последнее выглядит значительно более бредово, однако тогда редактор должен как-то уметь определять основной диапазон сигнала, в нужных местах лимитируя его 0дБ, и более того, должен уметь маппировать (строить отображение одного множоество на другое) на инты максимально хорошо - так, чтобы "промежуточные между целыми" значения не потерялись. Т.е. например, чтобы 7.00001 перешло в 14, 7.52337 - перешло в 15, а 7.9988999 перешло в 16. При этом надо вместится в `16-24` бита звуковой карты.
При всей сложности вопроса, я тем не менее не думаю, что алгоритмы разных редакторов принципиально разные. Скорее всего все различия происходят в
1) клиппировании лимитированного сигнала - например сонар может просто обрезать, а куба - обрезать мягче (т.е. чуть скруглить сигнал в окрестностях пика так, чтоб он был нерезкий), однако такая проблема элементарно решается любым пик-лимитером.
2) Не стоит забывать и про дизеринг - здесь он тоже понадобится, хотя скорее из-за того, чтобы сгладить накапливающуюся составляющую ошибку округления, возникающей при работе с "плавающими" числами. В этом отноншении Сонар опять же имеет свой дизер, но управлять им мона на вкл/выкл. В то время как тот же куб имеет внешний управляемый дизер. Хорошо это или плохо - хороший вопрос и дать на него сразу ответ, что куба или лоджик или сонар или самплитуда или кто угодно рулит - опять же бредово. Мало ли например как там заоптимизирован дизер в сонаре под его движок - непонятно. Результат кстати он даёт ИМХО очень неплохой при его включении.
Так что если я в чём-то неправ. Поправляйте меня. Буду рад выдержать здоровую критику с тем, чтобы окончательно разобраться сколько травки кладут в компакт-диски с кубой или другими редакторами
. А может у них интерфейс помигивает 25-м кадром Вот.
