Spectralyzer [AIMP 5.00]

[Artem]

В v2.01.14 (02.04.2022) плагине ни память, ни процессор не тратится сразу после появления окна, и вторая вкладка открывается моментально, то есть она уже просчитана.

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

[heroclix]

Да ничем он не лучше, там вагон багов. Поэтому и прошу его не выкладывать.

Удивительно, но я ни разу не столкнулся.

Но мне особо этот плагин уже не нужен, я теперь использую third party программы, которые работают в 2 раза быстрее (сами вычисления ещё быстрее), они многопоточные (ядер у меня мало), это с учётом что им нужно запуститься (запуски отдельных процессов занимают у меня 32+ мс). Я заметил что этот плагин однопоточный.
Вот тесты на 4 min flac:
spectralyzer plugin - 1481 ms - долго ждать, не использую
spectrogram third party - 642 ms
spectrum third party - 488 ms (250 ms занимает декодирование аудио и вычисление FFT 16384 bins (из 250 само вычисление FFT занимает 143 ms)), остальное это отрисовка картинки(этот этап медленный - 58 ms, можно быстрее сделать), её кодирование в png, сохранение, запуск third party программы просмотра картинки и прочее по мелочи. Здесь запускаются 3 процесса, это занимает ~90 ms из 488. здесь и разрешение рисунка выше, чем в spectralyzer plugin. У меня хоткей не очень удобный на это стоит, его нажать дольше, чем весь процесс

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

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

[Artem]

Но мне особо этот плагин уже не нужен, я теперь использую third party программы, которые работают в 2 раза быстрее (сами вычисления ещё быстрее), они многопоточные (ядер у меня мало), это с учётом что им нужно запуститься (запуски отдельных процессов занимают у меня 32+ мс). Я заметил что этот плагин однопоточный.

Ок, вопросов больше не имею.

[adem]

v6.00.3086 Beta 6
GTK3-64-bit (25.09.2026)
Linux / CachyOS rolling / KDE on WAYLAND
Spectralyzer v2.13.34

1. ПКМ по дорожке > Спектральный анализ
2. В окне Результата анализа «Сохранить как...»
3. Выбрать папку и Сохранить

Результат: png-файл не сохранился, в журнале/терминале:

Code: [Select]

Gtk3WidgetSet RawImage_DescriptionFromBitmap Error - invalid bitmap  = 139766433755904!
Gtk3WidgetSet RawImage_DescriptionFromBitmap Error - invalid bitmap  = 139766433755424!Видео: https://drive.google.com/file/d/1PImI2YLIzakffNAH70xwIkyIrtQrY0Zo/view?usp=drive_link

[Artem]

Да, есть такое. Поправил

[Desert dessert]

Как удобно!

А есть ли какие-нибудь гайдлайны по тому, каков «эффективный битрейт» (предполагаемый до предполагаемого апсемплинга)? Я читал какие-то эвристики, но забыл. Собирался себе делать пакетный анализатор на питоне, чтобы натравить сразу на все файлы и потом разбираться, где совсем уж подозрительная разница между битрейтом и границей частот, и где поменьше и пр., но руки не доходили, так что я не проверял, насколько те эвристики осмысленны, ведь они вообще зависят от энкодера.

Так вот если всё-таки более-менее точно можно определять, апсемпл с какого битрейта был, можно ли добавить это в данные там сбоку от спектрограммы?

[Artem]

эффективный битрейт

Нет, это зависит от кодека. Важен не битрейт, а срез частот, именно это говорит о качестве сохранённого сигнала

[Desert dessert]

Нет, это зависит от кодека. Важен не битрейт, а срез частот, именно это говорит о качестве сохранённого сигнала

Согласен, что одна часть вреда апсемпла mp3 именно в том, что урезанный спектр остаётся урезанным, просто апсемпл из совсем уж низких битрейтов не выше ~128 kbps кроме урезанных частот сохраняет ещё другие заметные ухом артефакты (по крайней мере для многих файлов из прошлого). Потому мне как-то проще было представлять в виде битрейта, его-то (для не перекодированных файлов) обынчо было видеть легче, чем реальную границу частот в файле. Да, надо видимо переориентироваться на неё...

[Artem]

Согласен, что одна часть вреда апсемпла mp3 именно в том, что урезанный спектр остаётся урезанным, просто апсемпл из совсем уж низких битрейтов не выше ~128 kbps кроме урезанных частот сохраняет ещё другие заметные ухом артефакты (по крайней мере для многих файлов из прошлого). Потому мне как-то проще было представлять в виде битрейта, его-то (для не перекодированных файлов) обынчо было видеть легче, чем реальную границу частот в файле. Да, надо видимо переориентироваться на неё...

Еще раз говорю, соотношение битрейта к качеству зависит от формата, 128 для mp3, совсем не тоже самое, что для AAC или OGG. К тому же, никто не мешает апсемлеру перегнать MP3 во FLAC и выдавать его за high-res.

[Desert dessert]

Да, я говорил только про MP3, потому что с файлами в других lossy форматах обычно не попадаются апсемпленными (в моём опыте). И я в курсе, что даже разные кодеки для MP3 могут выдавать результат разной сносности для низких битрейтов. Конечно и тот же OPUS в 128 kbps прекрасен, но это вещь такая недавняя, что уже вряд ли попадутся файлы, специально кем-то сконвертированные из низкобитрейтных MP3 в OPUS.

[Artem]

Да, я говорил только про MP3, потому что с файлами в других lossy форматах обычно не попадаются апсемпленными (в моём опыте). И я в курсе, что даже разные кодеки для MP3 могут выдавать результат разной сносности для низких битрейтов. Конечно и тот же OPUS в 128 kbps прекрасен, но это вещь такая недавняя, что уже вряд ли попадутся файлы, специально кем-то сконвертированные из низкобитрейтных MP3 в OPUS.

Мир не ограничивается одним MP3. Поэтому оценивать по битрейту нельзя, а по частоте - можно.

[Desert dessert]

Уф, я не знаю, как мне писать, чтобы недопонимания было меньше. Я не предлагал не оценивать файлы остальных форматов, это всё очень полезно.