[repstosw 18]

Подскажите кодек для сжатия музыки, можно с потерями.

 

Требования к кодеку:

 

1) Должен быть опенсорсным и написан на C/C++ (кроссплатформенность и следование ANSI C приветствуются)

2) Декодирование занимает не более 80 миллиоонов операций в секунду

3) Поддерживается фиксированная длина одного фрейма (пакета) сжатия

4) Регулируемая длина в байтах одного фрейма

5) Можно на floating point

6) Требования к декодированию с любого места - отсутствуют, мне нужно последовательно декодировать

 

Всякие MP3 не прокатывают ввиду их относительной жручести и кривого размера одного фрейма.  ADPCM не подходит из-за низкого коэффициента сжатия 4:1

Изменено 25 декабря, 2019 пользователем repstosw

[repstosw 18]

Opus.   Поддерживает регулируемую длину фрейма при условии если выбран флаг CBR.   Мои задачи решает!   Жаль что  нет 32 кГц семплрейта, прийдётся пересемплировать ручками 48->32 кГц

[blackfin 16]

1 hour ago, __inline__ said:

Всякие MP3 не прокатывают ввиду их относительной жручести и кривого размера одного фрейма.

MPEG-1_Audio_Layer_II относительно простой и не требует большого числа MIPS'ов.

[repstosw 18]

3 minutes ago, blackfin said:

MPEG-1_Audio_Layer_II относительно простой и не требует большого числа MIPS'ов.

Ого! 32 кГц семплрейт, что надо! Спасибо!

 

P.S. хотя, не пойдёт.  Рано радовался:

 

Quote

Размер кадра для уровня Layer II составляет 1152 отсчёта.

 

Надо чтобы размер семплов был фиксированным и задан.

 

Так что пока вижу Opus без вариантов + ресемплирование 48->32

Изменено 25 декабря, 2019 пользователем repstosw

[blackfin 16]

6 minutes ago, __inline__ said:

Надо чтобы размер семплов был фиксированным и задан.

А для чего это нужно?

[repstosw 18]

5 minutes ago, blackfin said:

А для чего это нужно?

Для того чтобы другие системы засинхронизировать от прерывания по опустошению звукового буфера с заданным интервалом.   Нужен определённый размер буфера или кратный целому числу от минимального размера. ))

 

Нужен буфер на 480 или 512 семплов.

Изменено 25 декабря, 2019 пользователем repstosw

[thermit 1]

mp3-2-1 подходит. пункт 4 реализуется независимо.

[repstosw 18]

10 minutes ago, thermit said:

mp3-2-1 подходит. пункт 4 реализуется независимо.

 

Каким образом?

[blackfin 16]

23 minutes ago, __inline__ said:

Для того чтобы другие системы засинхронизировать от прерывания по опустошению звукового буфера с заданным интервалом.

Что за "другие системы"? И почему их нужно синхронизировать с "опустошением звукового буфера с заданным интервалом"?

ИМХО, сами себе придумываете проблемы..

[thermit 1]

1 час назад, __inline__ сказал:

 

Каким образом?

Руками. Или ногами. Кому чего всевышний отвесил. Если есть конкретные вопросы - задавайте.

[repstosw 18]

12 hours ago, blackfin said:

Что за "другие системы"? И почему их нужно синхронизировать с "опустошением звукового буфера с заданным интервалом"?

"Потому  что гладиолус! ..." (c)

 

11 hours ago, thermit said:

Руками. Или ногами. Кому чего всевышний отвесил. Если есть конкретные вопросы - задавайте.

Да тут всё понятно.  Сделать это можно, но через большую ... (так, а где тут смайлик с поворачивающейся жопой? :)   раньше был такой!)

[repstosw 18]

Проделал ряд экспериментов с кодеками на ПК и на доске с C6745.

 

1) Кодек MP2.  На 32 кГц 48 кбит/c  1 канал - качество заметно хуже,  чем у MP3 на тех же параметрах.  Конкретно -  сильно режет высокие частоты, звук как будто приглушён.

 

2) Кодек Opus.  Ребята из Xiph.org  явно перегнули палку с ним. Нет никакого кодека Opus на самом деле.  Есть два разных кодека: для речи- SILK,  для музыки  -CELT.   То, что называется Opus'ом - это некая предварительная прослойка, которая анализирует фрейм и  параметры:  если фрейм речевой - отсылает на SILK,  если музыкальный - то отсылка на CELT.   При этом, конечно,  сжирается некий вычислительный процент на такой анализ.    А у меня чисто музыка.   Поэтому было решено перейти к кодеку под пунктом 3) ниже:

 

3) Кодек CELT.   Конкретно собрал версию 0.9.0.  Хватает за глаза!  Читаем описание и видим: поддержка семплрейта от 32 (!!!)  до 96 кГц - то что мне нужно!!!  А в Opus 32 кГц запретили.  Далее - размер  фрейма : от 64 до 512 семплов.   Нет привязки к тупым миллисекундам как в Opus !    Итоговый битрейт считается как :

BitRate = FrequencySample/FrameSize*CompressedFrame*8
  
BitRate  -битрейт бит/c
FrequencySample - частота дискретизации Гц
FrameSize - размер фрейма (исходного) в семплах (1 семпл  = 2 байта)
CompressedFrame  - размер фрейма (сжатого) в байтах

 

По формуле выше определяется размер сжатого фрейма, при заданном целевом битрейте (выходном).

 

Результаты ошеломляющие - без всяких спец-оптимизаций и интринсиков удалось декодировать на лету фреймы  всего 0,96 мс при таких параметрах:  1 канал, 48 кбит/c, 32 кГц, размер разжатого фрейма 512 семплов.

 

Выходит в Opus жестко ограничили возможности CELT'а и притормозили его!

 

А вот если переписать mathops на интринсики C6745, думаю можно ещё больше ускорить работу  кодека.   И по качеству CELT сравним с MP3 и превосходит MP2 на одинаковых параметрах.

Задача выполнена.

 

Кодек CELT с исходниками: http://www.celt-codec.org/downloads/

 

Моя байда с проверкой кодека на ПК:

 

Spoiler

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include "celt.h"
#include "arch.h"
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>

#define FS 32000
#define IN 512
#define OUT 96

int main(int argc, char *argv[])
{
 FILE *fi;
 FILE *fe;
 FILE *fo;

 celt_int16 *in;
 unsigned char *en;
 celt_int16 *out;

 CELTMode *mode=NULL;

 CELTEncoder *enc;
 CELTDecoder *dec;

 celt_int32 skip;

 int err;

 mode=celt_mode_create(FS,IN,NULL);
 celt_mode_info(mode,CELT_GET_LOOKAHEAD,&skip);

 in =(celt_int16*)malloc(IN*sizeof(celt_int16));
 en =(unsigned char*)malloc(OUT);

 enc=celt_encoder_create(mode,1,&err);

 fi=fopen(argv[1],"rb");
 fe=fopen(argv[2],"wb");
 
 while(!feof(fi))
 {
  fread(in,2,IN,fi);
  celt_encode(enc,in,IN,en,OUT);
  fwrite(en,1,OUT,fe);
 }

 fclose(fi);
 fclose(fe);

 celt_encoder_destroy(enc);

/*
 out=(celt_int16*)malloc(IN*sizeof(celt_int16));

 dec=celt_decoder_create(mode,1,&err);

 fe=fopen(argv[2],"rb");
 fo=fopen(argv[3],"wb");

 while(!feof(fe))
 {
  fread(en,1,OUT,fe);
  celt_decode(dec,en,OUT,out,IN);
  fwrite(out+skip,2,IN-skip,fo);
  skip=0;
 }

 fclose(fe);
 fclose(fo);

 free(out);
 free(en);
 free(in);

 celt_decoder_destroy(dec);
*/

 free(en);
 free(in);


 celt_mode_destroy(mode);

 return 0;
}

 

 

Изменено 28 декабря, 2019 пользователем repstosw

[repstosw 18]

Переписал mathops.h на интрисинки C6745 и включил быструю аппроксимацию в config.h - скорость декодирования выросла : теперь фрейм разжимается 0,56 мс.   Но можно было и не оптимизировать, а включить FIXED_POINT в config.h и пересобрать.  Вариант FIXED POINT на 5% быстрее оптимизированного FLOATING POINT + FAST APPROX.

 

Пробовал CELT 10 и 11 версии.  11-я версия пошла фтопку, так как кодек отказался работать на моём формате.  А вот 10-я версия работает, хотя пакеты несовместимы с 9-й.  Оставил 10-ю версию.  Всё что выше 10й - уже похерено Опусом.