Фазовое кодирование аудиофайлов - печальная проблема.

[dar3dev1l26]

Пытаюсь спрятать в фазовую область аудиофайла информацию, всё делаю по книге:

Всё сделал, должно работать как часы, но вот на практике работает только частично. Во-первых денные зеркально дублируются - сначала идут нужные данные, потом столько же ненужных зеркально отраженных, но это не страшно, можно поделить контейнер на 2 и не читать их. Вторая проблема хуже - если надо спрятать маленькое сообщение (до 64 символов) то всё работает, если больше - начинается искажение, массив фаз не такой, каким должен быть (как будто погрешность появляется). Проиллюстрирую на примере.
Случай 1 - прячу сообщение "Hello", на выходе получаю фазы:
[0]
-0.79
0.785
-0.784
-0.784
0.786
-0.785
-0.786
-0.78
[1]
-0.786
0.786
0.785
-0.786
-0.785
0.784
-0.789
0.787
[2]
-0.788
0.785
0.785
-0.785
0.786
0.786
-0.786
-0.784
[3]
-0.786
0.785
0.784
-0.785
0.786
0.786
-0.786
-0.784
[4]
-0.785
0.8
0.762
-0.791
0.805
0.806
0.819
0.757
[5]
-0.039
-0.064
0.007
-0.001
-0.093
0.007
-0.025
0.04
[6]
-0.064
0.162
0.063
0.021
-0.03
-0.226
-0.138
-0.026
[7]
0.13
-0.046
-0.36
-0.033
-0.104
0.081
0.154
0.038
========
Ненужные биты отсеиваются так - всё что больше П/6 и меньше -П/6 - нужные данные.
В данном случае +0.7 - соответствует биту 1, а -0.7 - биту 0, получаем:
[0]~01001000 [1]~01100101 [2]~01101100 [3]~01101100 [4]~01101111 [5]~10101010 [6]~10010001 [7]~01110110
========
Переводим в строку: Helloª‘v
Всё работает верно - излишок не страшен, главное сообщение я получаю полностью.
Когда надо закодировать больше символов появляется "погрешность", в начале идут цифры типа -0.79, 0.785 и т д, но потом появляются абракадабры типа -0.563, -0.027, чем больше букв кодируем - бем больше искажение, иногда цифры переваливают за 0 и МЕНЯЮТ знак. Тогда чем больше сообщение - тем меньше бит я смогу расшифровать. Подскажите кто разбирается в дискретном преобразовании Фурье что может быть не так, откуда искажение?Я всё что мог уже перепроверил, два дня страдаю, я всё правильно по формулам делаю, ДПФ отдельно тоже работает (без модификации фазы).

[s-andriano]

Чудес не бывает - сколько бит Вы пытаетесь впихнуть на Кбайт звукового файла?

[dar3dev1l26]

Соотношение скрываемая информация:аудио данные - 1:4. То есть на 16 бит скрываемой информации приходится 64 единицы аудио данных. Это 2^8-битовое целое для стерео или 2^16-битовое целое для моно (wav). По-моему достаточно, на слух не слышно разницы.
Я понимаю что чудес не бывает, я всё уже перепроверил 100 раз, всё по отдельности работает, я думаю в книге просто не указано это отклонение, может быть оно так и должно быть... Если бы была формула как посчитать это оклонение, может быть бы получилось.

[s-andriano]

Сообщение от dar3dev1l26

Соотношение скрываемая информация:аудио данные - 1:4. То есть на 16 бит скрываемой информации приходится 64 единицы аудио данных. Это 2^8-битовое целое для стерео или 2^16-битовое целое для моно (wav). По-моему достаточно, на слух не слышно разницы.

Не верю!
Сокращение объема аудиоданных на 20% не может не сказаться на качестве звука.
Не заметить этого можно только, если прослушиваешь запись через компьютерные пластмассовые колонки ценой $20.

В алгоритме не разбирался, но мне кажется, если есть желание добиться результата, соотношение нужно радикально поменять, чтобы на скрытые денные приходилось менее 1% (и, соответственно, сокращение объема звуковых данных не превышало этого самого 1%).

Я понимаю что чудес не бывает, я всё уже перепроверил 100 раз, всё по отдельности работает, я думаю в книге просто не указано это отклонение, может быть оно так и должно быть... Если бы была формула как посчитать это оклонение, может быть бы получилось.

Что за отклонение, не понял, но если Вы имеете эффект, при котором маленький объем информации хорошо кодируется в маленьком файле, а большой - плохо в большом, то выход мне кажется очевидным:
Разбивать скрываемую информацию на небольшие фрагменты и каждый из этих фрагментов размещать независимо в небольшом отрезке звукового файла.

[dar3dev1l26]

Вы не поняли, я меняю не сами аудиоданные на +\- П/2, а фазу. Я применяю БПФ к массиву аудиоданных, разбиваю его на массив фаз и амплитуд, меняю фазы где мне нужно, синхронизирую с фазами других кусков(в которых нет скрываемых данных), потом из старого массива амплитуд и модифицированного масива фаз по формуле получаю другой массив, применяю обратное БПФ и получаю массив, который лишь немного отличается от входного. Поэтому не слышно искажений.
Я уже думал над тем, чтобы БПФ применять на меньшие кусочки и несколько раз встраивать информацию, я проверил например - БПФ(1,2,3,4) не равняется БПФ(1,2) + БПФ(3,4), в результате если так поступить, то массивы фаз будут разными и я не знаю как синхронизировать их всех в одном аудиофайле - вот тогда будут слышны помехи. То есть результат БПФ зависит от размера массива.

[s-andriano]

Мне кажется, проблемы возникают на самом раннем этапе:
фаза - это часть аудиоданных, а не что-то внешнее и лишнее.
Изменяя фазу, Вы искажаете звук.

Разбираться в алгоритме, честно говоря, нет никакого желания, но если бы передо мной стояла задача аналогичная Вашей, то мною бы алгоритм, искажающий аудиоданные на 20% был бы отвергнут только по этому признаку.
Судя по Ващим сообщениям, Вы тоже не особо пытались разобраться в алгоритме, используя лишь "формулы" без понимания, как эти формулы получены и в каких условиях ими можно пользоваться.
А это значит, что возможен целый ряд "подводных камней", начиная от ошибок в формулах или неверного их применения, и заканчивая тем, что разработчик алгоритма изначально вольно или невольно вводит читателя в заблуждение относительно свойств алгоритма.

[dar3dev1l26]

Нету 20% искажений, я же писал выше. Эти 20 процентов вносятся в фазу заукового отсчета, фаза может быть 0 .. 2*Пи, как у синуса или косинуса, потом остальные данные синхронизируются.
В том-то и дело что всё сделано как надо, но на практике не работает. Думал кто-то может подсказать почему ДПФ для одинаковых закодированных данных в масиве фаз (+\- Пи/2) возвращает не одинаковые (примерно) значения. Погрешность должна быть маленькой, а она огромная. Я на погрешность никак не могу повлиять, на нее влияют как я понял только погрешности компьютерных рассчетов. В чистой математике никакой погрешности бы небыло. Я думаю дело в том, что у меня аудиоданные типа short (2^16 битовое целое), думаю если бы это было, к примеру 2^8 битовое целое таких погрешностей бы небыло.

[dar3dev1l26]

И да, еще одно - я ОСОБО пытался разобраться, несколько дней только и делаю, что исследую каким образом можно повлиять на погрешность. Я просто уже не знаю что делать.

[raxp]

...погрешность идет хотя бы уже от того, что вы делаете последовательность прямого и обратного преобразования Фурье. Количество точек, а значит получаемых гармоник и восстановленных отсчетов от количества исходных отличается (минимум в два раза меньше). Даже, если вы и с точностью до герца считаете.

[dar3dev1l26]

Вот это полезное сообщение. Я использую функцию БПФ с википедии (для с#), у меня после преобразований размер массива не меняется, но зеркально дублируются данные внутри него. Я их просто отсекаю когда ищу нужную мне информацию. Можете пожалуйста объяснить почему БПФ должна размер 1:2 иметь и может ли быть моя проблема в том, что у меня эта функция неправильно работает изза того, что возвращает такое же число значений?
Вот моя функция:

public class FFT
    {
        /// <summary>
        /// Вычисление поворачивающего модуля e^(-i*2*PI*k/N)
        /// </summary>
        /// <param name="k"></param>
        /// <param name="N"></param>
        /// <returns></returns>
        private static Complex w(int k, int N, bool b)
        {            
            if (k % N == 0) return new Complex (1,0);
            double arg; 
            if (b == false) arg = -2 * Math.PI * k / N; 
            else arg = 2 * Math.PI * k / N;
            return new Complex(Math.Cos(arg), Math.Sin(arg));
        }
        /// <summary>
        /// Возвращает спектр сигнала
        /// </summary>
        /// <param name="x">Массив значений сигнала. Количество значений должно быть степенью 2</param>
        /// <returns>Массив со значениями спектра сигнала</returns>
        public static Complex[] fft(Complex[] x, bool b)
        {
            Complex[] X;
            int N = x.Length;
            if (N == 2)
            {
                X = new Complex[2];
                X[0] = x[0] + x[1];
                X[1] = x[0] - x[1];
            }
            else
            {
                Complex[] x_even = new Complex[N / 2];
                Complex[] x_odd = new Complex[N / 2];
                for (int i = 0; i < N / 2; i++)
                {
                    x_even[i] = x[2 * i];
                    x_odd[i] = x[2 * i + 1];
                }
                Complex[] X_even = fft(x_even,b);
                Complex[] X_odd = fft(x_odd,b);
                X = new Complex[N];
                for (int i = 0; i < N / 2; i++)
                {
                    X[i] = X_even[i] + w(i, N,b) * X_odd[i];
                    X[i + N / 2] = X_even[i] - w(i, N,b) * X_odd[i];
                }
            }
            return X;
        }
        /// <summary>
        /// Центровка массива значений полученных в fft (спектральная составляющая при нулевой частоте будет в центре массива)
        /// </summary>
        /// <param name="X">Массив значений полученный в fft</param>
        /// <returns></returns>
        public static Complex[] nfft(Complex[] X)
        {
            int N = X.Length;
            Complex[] X_n = new Complex[N];
            for (int i = 0; i < N / 2; i++)
            {
                X_n[i] = X[N / 2 + i];
                X_n[N / 2 + i] = X[i];
            }
            return X_n;
        }
    }

Я пользуюсь так: arr = FFT.fft(arr, false(прямое)\true(обратное));
Я проверял прямое и обратное преобразование, например если я создаю массив {1,2,3,4}(я и большие создавал), то после прямого и обратного преобразования получал тот же массив ({1,2,3,4}). Я думаю всё работает правильно.