I.
Считается, что самый лучший на сегодня НСФ-плеер - это NSFplug (winamp) или NSFplay (тот же nsfplug, только с оболочкой, standalone). Плеер точный, с качественным алгоритмом передискретизации (в отличие от НотСоФатсо), и множеством настроек. Потербляет 500~1000 Мгц CPU, в зависимости от выбранного качества ресемплинга. Но он не умеет ограничивать скорость NTSC NSF-ок до 50 FPS, как это делает НотСоФатсо. Принудительно PAL в нём тоже не сделаешь, хотя, если в NSF-ке стоит флаг PAL-режима, плеер её играет на скорости 50. Это я проверил с помощью фамитрекера (там галка есть, при экспорте проекта в NSF - set PAL flag in NSF header).

Чтобы вручную выставить PAL флаг в заголовке, решил изучить документы:
http://kevtris.org/nes/nsfspec.txt

Флаг менял следующим образом:

0000 0000 = 00Н = NTSC
0000 0001 = 01H = PAL
0000 0010 = 02H = NTSC/PAL

GManiac и человек с форума nesdev.com подтвердили, что метод правильный, ошибки нет.

Преимущества этого метода
- абсолютное большинство эмуляторов и плееров определяют PAL-флаг, и играют NSF на скорости 50 FPS.
Это полезно для тех плееров/плагинов, где PAL невозможно выставить принудительно. (nsfplug/nsfplay, nezplug++ и т.д.)

Недостатки этого метода
- почти все эмуляторы и некоторые плагины (notsofatso, nezplug++) играют PAL правильно: т.е. высота тона основных каналов понижена, а высота тона DPCM аналогична NTSC => слышен неприятный дисбаланс.
Хотя, к счастью, nsfplay/nsfplug лишен этого недостатка. Плагин просто запускает PAL-NSF-ки на скорости 50FPS.
Высота тона всех каналов соответствует NTSC. Эта формальная неточность плагина играет нам на руку.

II.
HardWareMan дал мне свою бета-программку, которая превращает NTSC NSF-ки в PAL.
(upd 13.07.10 сейчас утилита "доводится до ума", скоро будет доступна для свободного скачивания)

Эта программа не меняет флаг, в ней используется другой метод (какой именно, я не уточнил).
Это позволяет запускать НСФ-ки на скорости 50 в плеерах, где PAL вообще не предусмотрен и флаги игнорятся.
Но это работает не всегда, хотя nsfplay/nsfplug и in_nintendulator.dll понимают НСФки, хакнутые этой прогой.

Главное достоинство метода - если плеер/эмулятор корректно воспринимает такую NSF-ку,
дисбаланса по высоте тона гарантированно не будет.
Файл либо не воспринимается, и играется на скорости 60, либо воспринимается и играется замедленно на 50,
при NTSC-шной высоте тона всех каналов. Это наиболее "похожий на денди" вариант.

Это можно проверить на плагине NEZplug++, который "некрасиво" играет NSF-ки с PAL-флагом (хакнутые первым методом)

Вот честное слово, не верю я в эти сказки о причинах сверх-тормознутости. Ладно, если эмулятор всей приставки или даже обрезанный вариант - NSF-плеер - CPU + APU. Но алгоритм ресемплирования - никак.
Самый лучший (можно сказать, идельаный) алгоритм основывается на ДПФ. Я проводил простые расчёты: выборку в 32768 семплов библиотека fftw в Матлабе обрабатывала что ли за 3 мс. Возьмём тяжёлый вариант: берётся выборка за всю секунду и ресемплируется. Даже если перевести это на выборку в 100к семплов (увеличение в 3 раза, домножение на разницу в логарифмах, плюс плохая факторизация числа) и ресемплирование до 44100 (то же самое, но влияет меньше, т.к. число меньше), умножить на 2 канала, получится... ну пусть 50 мс. Это 5% от мощности компа.
В реальности надо ресемплировать небольшими окнами размером по 4096 семплов (разницы относительно 32768 не будет), и вычислений получается раза в 2 меньше. Итого 2.5% мощности компа.

-- 06 июл 2010, 15:20 --

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

На официальной странице указаны именно такие требования. В реальности же, я тестировал Lagrange Point (с VRC7)
при максимально возможном качестве передискретизации для всех эмулируемых чипов на Pentium III (tualatin) 1.13 ГГц.

Загрузка процессора ~30%, изредка до 50% подскакивает.

А вообще, почему тогда качественные плагины программной передискретизации такие прожорливые (например SRC (libsamplerate) и SSRC)?

По второй ссылке упоминается использование ДПФ (FFT). Не знаю, насколько они прожорливые, не проверял. Почему - возможно, потому что используют самописные алгоритмы преобразования, и тот факт, что пропорции для преобразования плохо факторизуются и тем более не являются степенью двойки, играет огромную роль. А fftw - одна из мощнейших бесплатных либ в этом деле.
К примеру, Audition быстро и хорошо всё конвертит, правда, зачем-то применяет пост-фильтрацию. И да, Audition использует fftw.

SSRC (по второй ссылке) считается вообще одним из самых прожорливых конвертеров.
Но в тоже время, пока он и самый качественный. Видимо, поэтому:

Писал его Naoki Shibata (PhD, Computer Science, 1993—2001)

SSRC загружает PIII-1.13 минимум на 60%, я заметно тормоза чувствую при использовании.

И, кстати: Страница Бульбы.

Простой пример: возьми проф. аудио редактор, открой файл длиной в несколько минут и сконвертируй его из 44100 в 48000. Посчитай, сколько времени это займёт и раздели на длину трека - это и будет процент прожорливости редактора.

-- 06 июл 2010, 16:10 --

Щас взял Аудишн, трек в 5 минут и апсемплил до 48000. Апсемплинг занял ~12... вру, 8 секунд, пост-фильтрация - 5 секунды. Используется Dual-Core 2 ГГц.

На моей машине 4-х минутный трек ресемплировался до 48000 Гц за ~3.5 мин. Сейчас точно посчитаю...

может, с качеством переборщил.
CoolEditPro 2.1
-----------------------------------------
upd. ресемплинг закончился в 3:43, пост-фильтрация в 4:15. Итого 4.15

Вообще-то я пользовался всегда авторесемплингом при копировании куска из одного файла в другой. Видимо, там по умолчанию качество низкое выставлено... не знаю, но качество всегда было нормальным.
Можно привести пример теста: я строил кривую АЧХ при временнОм разделении каналов, когда один канал в фазе, другой в противофазе. В зависимости от семплов. Это делалось просто чтобы посмотреть, сильно ли меняется конечный сигнал при временнОм смешивании вместо суммирования. Потом опишу, как делается тест.

Щас открыл это окно в Аудишне. На максимальном качестве 5-минутный трек обрабатывается 35 секунд.
Как он измеряет качество, не знаю, может, размером выборки? При максимальном качестве, наверно, выборка гигантская, поэтому так долго.

core2duo 2.0 и P3 1.13 это небо и земля. Плюс ко всему - SSE2, SSE3, SSSE3 всякие... их нет у меня

Если кому интересно, хотя мы уже отошли от темы, как делался мой тест с временным смешиванием.
Создаём 2-хканальный трек, генерируем свип частоты от 1 до max (т.е. скользящая частота), затем второй канал инвертируем.
Сохраняем файл как двухканальный и открываем как одноканальный (можно в хекс-редакторе в заголовке трека прописать ручками, что он одноканальный - там, где написано 0200, надо вписать 0100). Это простой способ сымитировать временное смешивание каналов.
В спектрограмме мы увидим скользящую частоту вверх и её отражение сверху - всё верно. Даунсемплим трек ровно в 2 раза. Как я и рассчитывал по матрицам и векторам в ДПФ, на низких и высоких частотах противофазные каналы имеют совсем разный эффект. Если каналы ставить в синфазе, всё наоборот.

Тот же пример я ресемплировал в SoundForge 9 простым копированием. На моё удивление противофазные каналы "съели" друг друга и получилась тишина. Хотя все расчёты показывают, что это неверно.


Dual-Core вообще-то. Хотя он несильно слабее. Я же не знал, что за зверь-машина у тебя

-- 06 июл 2010, 16:49 --

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

Возвращаясь к теме передискретизации, раз уж пошло: есть такой знаменитый плеер трекерных форматов - xmplay 3.5.1.
Мне очень нравится SID-плагин для этого плеера. Ознакомиться можно здесь. Звук у него действительно очень приятный.

Так вот, при использовании наилучшего метода "resampling with interpolation"

тормоза и заикания ощущаются на P4 2.7 ГГц (если стоит stereo-режим), я не шучу.
О чём, собственно и написано на скриншоте.
Я прикрепил последнюю версию xmp-sid плагина: rev26 (31.01.2010). На официальном сайте старая лежит.

Аналогичная ситуация и с MilkyTracker. Если вы хотите перевести *.xm или другой модуль в *.wav
используя при этом максимально возможное качество ресемплинга, ждать придётся очень дооолго:

Крупным модулям даже на мощных машинах по полчаса требуется.

Раз так, решился я и откопал свои наработки по ресемплеру (они всегда сырые были, т.к. слиьно ими я не занимался).
Для примера беру трек Regurgitate - Vulva Fermentation 2002-го года, 44100 Гц, имеющийся у меня в лосслессе. В треке всё забито до упора и после ресемплинга возможен клиппинг, поэтому амплитуду я уменьшил в 1.25 раза. И работал только с левым каналом для простоты и чтобы на скринах было видно больше информации.
На всех скринах показаны первые 10 секунд треков. Настройки спектрограммы в Audition:
Windowing Function - "Blackamn-Harris"
Resolution - 1024 для 22050-герцовых треков и 2048 для 44100-герцовых.
Decibel Range - 160 dB.
Диапазон дБ влияет на яркость спектрограммы.
Почему используется разное разрешние для разных треков? В оригинальных (44100) пусть будет 2048 полос, тогда толщина полосы = 22050 / 2048 = 10.76... Длина окна = 4096 семплов = 0.093 секунды.
В даунсемплированном треке частота меньше в 2 раза (22050), поэтому полос должно быть в 2 раза меньше. Тогда их толщина = 11025 / 1024 = 10.76... И длина окна тоже будет совпадать.
По скринам вы поймёте, что всё сделано правильно, т.к. на них картины спектрограммы для треков разной частоты совпадают. А если оставлять Resolution одинаковые, картины бы не совпадали.

Скрины советую скачать и сверять их в просмотрщике с Zoom Lock и/или Pan Lock. Различия видны в верхней части спектрограммы.

Итак, вот картина с оригинального файла во весь рост (0-22050 Гц):
http://www.fileden.com/files/2009/4/23/ ... g_full.jp2
А вот нижняя половина спектрограммы (т.е. частоты от 0 до 11025). Именно такую картину мы должны увидеть в 22050-герцовом файле (но это будет уже не половина, а вся спектрограмма) после идеального даунсемплинга в 2 раза.
http://www.fileden.com/files/2009/4/23/ ... ig_1_2.jp2
Даунсемплим оригинал в Аудишне в 2 раза с качеством 30:
http://www.fileden.com/files/2009/4/23/ ... vu_030.jp2
С качеством 150:
http://www.fileden.com/files/2009/4/23/ ... vu_150.jp2
С качеством 999 (лучшее):
http://www.fileden.com/files/2009/4/23/ ... vu_999.jp2
Как видно, 30 и 150 отличаются несильно, 999 выглядит уже лучше. Видно также, что по мере увеличения качества картина приближается к оригиналу (нижняя половина частот), в основном на верхних частотах. Но даже 999-е качество немного не дотягивает до оригинала.
А теперь мой ресемплер:
http://www.fileden.com/files/2009/4/23/ ... /vu_my.jp2
Картина полностью совпадает с оригиналом, только в левом верхнем углу небольшая вертикальная фиолетовая полоска, но это мелочь.
Также заметно, что у моего трека другая длина - это потому что я ресемплил один кусок, а не весь трек.

Выводы: мой метод работает. Вычисления скорости выше. Кстати, я никогда не читал о ресемплинге, а этот метод придумал сам путём простых рассуждений.
А если у других всё так медленно, я не виноват. Просто у них другие методы, выходит, не самые лучшие.

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

В таком случае, я думаю, надо не бросать этот проект "в стол", а попытаться применить его куда-нибудь с пользой.

Я залил полную GAME NSF-коллекцию, пропатченную HWM'овской утилитой.
Теперь вы можете использовать NSFplug/NSFplay в роли "истинного денди-плеера".

Обнаружил наконец, как избавиться от неприятных щелчков DPCM.
Также можно немного убрать бас HiPass фильтром, это уж на любителя.
Я например, без такой эквализации слушать NSF не могу - бас треугольника уши режет. И не во всяком эмуляторе ведь HiPass реализован.
Ползунок "Sample Rate Conversion" желательно выставить в BEST для каждого чипа.

Опять возвращусь к теме ресемплинга. Vortex AY-3-8910/YM2149F плагин v.4.0 от Романа Щербакова
использует **общепризнанный лучшим на сегодня** SSRC ресемплер, за авторством Naoki Shibata.
Бульба пишет, что это самый качественный AY-плеер (по крайней мере, по части передискретизации он превосходит AY_Emul).

Загруженность Pentium 1133 Мгц на абсолютно чистой системе: 90-95%

Интересует правильная настройка этих примочек:
dithering: 1) none; 2) no noise shaping; 3) triangular spectral shape;
noise distribution: 1) rectangular; 2) triangular; 3) gaussian;

Какие параметры выбрать для получения максимального качества при разрядности 16 бит и ч.д. 44100 Гц?

Rainwarrior взялся за доработку заброшенного nsfplay/nsfplug:
http://rainwarrior.thenoos.net/projects ... index.html
Напильником поработал прилично, см. changelog

Наконец-то добавлено панорамирование каналов:

NSFPlay 2.3

Больше не нужно "патчить" NSF-ки. Текущая версия поддерживает денди-режим.

Это единственный NSF-плеер на сегодня, поддерживающий денди.
А ещё он умеет менять скважность square-каналов 25% <-> 50%