LAME 3.100 (+ optimized version by tmkk) x86/x64
Хотя сегодня MP3 и не самый качественный lossy аудио кодек, он бесспорно является лидером за счёт своей огромной популярности и совместимости с практически любыми аппаратными и программными плеерами.
LAME (аббревиатура от LAME Ain’t an MP3 Encoder) — это свободное приложение для кодирования аудио в формат MP3 (MPEG-1/2/2.5 Layer 3). По показателям качества LAME даёт лучший результат среди кодеров МР3.
Настройка
Использование
Параметры
stereo
Кодер не использует возможность корреляции между двумя каналами, что может негативно сказаться на качестве в режиме CBR/ABR или неоправданно повысить битрейт для VBR. В этом режиме кодер предоставляет одному из каналов меньшее количество битов, если тот содержит тишину или же является менее сложным.
joint stereo
Кодер использует корреляцию между двумя каналами. Сигнал раскладывается на сумму Mid, рассчитанную как L+R, и разницу Side, рассчитанную как L-R, приоритет при распределении битов имеет канал Mid.
Такой прием эффективно увеличивает пропускную способность для сигналов с небольшим разделением стерео и даёт существенный прирост качества кодирования. Использование режима joint stereo совершенно безопасно, так как кодер может переключаться между Left/Right и Mid/Side представлениями на основе анализа степени разделения стерео (используется достаточно сложный алгоритм, описанный в документации ISO). Посмотреть количество фреймов для разных режимов можно, например, с помощью EncSpot.
forced joint stereo
Этот режим принудительно включает joint stereo для всех фреймов. Немного более быстрый, чем обычный joint stereo, использование рекомендуется только в тех случаях, когда вы уверены, что кодируемый сигнал имеет очень незначительное разделение стерео.
dual channels
В этом режиме 2 канала кодируются совершенно независимо. Каждому каналу выделяется ровно половина битрейта. Режим разработан для таких случаев, как, например, двуязычное кодирование (один язык в левом канале, другой язык — в правом). Использование данного режима для обычных стерео файлов приведет к более низкому качеству кодирования.
Lame MP3 для Windows
Lame MP3 — это одна из лучших программ-кодировщиков, предназначенных для перевода музыкальных файлов в формат MP3. Кодек обладает большим количеством настраиваемых параметров и позволяет создавать MP3-файлы по качеству практически идентичные оригинальным саундтрекам.
Lame MP3 распространяется с открытым исходным кодом, может работать как отдельная консольная программа или как Windows кодек (ACM).
Пакет всех самых необходимых кодеков, фильтров и плагинов для безпроблемного и.
Отзывы о программе Lame MP3
Саня про Lame MP3 3.99.5 [14-07-2013]
гена про Lame MP3 3.99.5 [30-05-2013]
Вася, это энкодер, а не Angry Birds)))/
3 | 3 | Ответить
VASYA про Lame MP3 3.99.5 [06-04-2013]
Херня какя-то. запускного файла нет. как с ней работать?? через программную строку. Ещё б через очко попробовали. хакеры хреновы.
2 | 10 | Ответить
dEEp013 про Lame MP3 3.99.3 [17-01-2012]
После 3.93 уже ничего качественнее не слышал, а жаль
3 | 4 | Ответить
Kokademon про Lame MP3 3.99.3 [16-12-2011]
Полная настройка LAME бесплатно (кодек, энкодер, дэкодер, кодер)
LAME (Lame MP3 Encoder) — это наш выбор и рекомендуемый MP3-кодировщик для сжатия аудио. Он был разработан сообществом разработчиков программного обеспечения с открытым исходным кодом с 1998 года и стал MP3 кодировщиком самого высокого качества для большинства целей.
История
Разработка LAME началась примерно в середине 1998 года. Майк Ченг начал его как патч против источников кодировщика 8hz-MP3. После некоторых проблем с качеством, поднятых другими разработчиками, он решил начать с нуля, основываясь на источниках dist10. Эта ветвь (патч со ссылочными источниками) получила название LAME 2.0. К выпуску LAME 3.81 весь код dist10 был удален, что сделало LAME совершенно новой программой, а не просто патчем существующего кодера.
См. также: Что такое Lossless?
Проект быстро стал коллективным усилием. Майк Ченг в конце концов оставил лидерство и начал работать над tooLAME, кодировщиком MP2. Марк Тейлор стал лидером и выпустил версию 3.0 с новой разработанной им психоакустической моделью gpsycho.
В настоящее время LAME считается лучшим MP3-кодировщиком на средних и высоких битрейтах и имеет лучшую модель VBR среди реализаций MP3, в основном благодаря преданной работе талантливых разработчиков Такехиро Томинага, Наоки Шибата, Дарина Моррисона, Габриэля Бувиня, Роберта Хегеманна и других. Разработка продолжается.
Хотя LAME обычно считается кодировщиком, согласно техническому FAQ LAME — это не кодировщик, а скорее просто «проект разработки, использующий модель с открытым исходным кодом для улучшения технологии MP3». Эта улучшенная технология выпущена только в виде исходного кода, чтобы минимизировать риск нарушения патентов. Когда исходный код компилируется и распространяется, ему может потребоваться лицензия от Thomson, в зависимости от того, где и как он будет использоваться. Позиция проекта LAME: «Исходный код рассматривается как речь, которая может содержать описания запатентованной технологии. Описания патентов находятся в открытом доступе».
См. также: Что такое Ogg Vorbis?
Исходный код LAME поддерживается в репозитории CVS, и единственная официальная база кодов для публичного использования — это транковый код с тегом «MAIN». Существует также множество экспериментальных веток этого кода, в которых разработчики проверяют новые идеи. Одна из этих веток была запущена после выпуска LAME 3.92 в 2002 году. Чтобы избежать путаницы с альфа-версиями LAME 3.93, был создан код, позволяющий идентифицировать себя как LAME 4.0 alpha 1 (в конце 2002 г.) — 4.0 alpha 14 ( с 2005 года). Этот код в основном предназначен для разработчиков, чтобы тестировать оптимизации и архитектурные изменения в базовом коде LAME, идеи, которые в конечном итоге могут быть использованы в основной ветке и когда разработка действительно начнется на LAME 4.0. Однако некоторые представители общественности использовали этот код для создания рабочих копий альфа-версий «LAME 4.0» в 2003-2005 годах. Они не должны рассматриваться как настоящие выпуски LAME 4.0, и разработчики не хотят, чтобы о них публиковали открытые отзывы, и не хотят, чтобы из этой ветви делались публичные сборки.
Рекомендуемые настройки кодера
Максимальное качество и архивация
Максимальное качество достигается, когда, независимо от условий прослушивания, вы не можете обнаружить разницу между MP3 и оригиналом. Как показали слепые тесты ABX, MP3-файлы с кодировкой LAME обычно достигают этого уровня прозрачности при кодировании с настройками по умолчанию, при битрейтах значительно ниже максимальных. Кодирование с более высокими настройками битрейта не повлияет на воспринимаемое качество.
Для архивирования идеальны только форматы без потерь, такие как WavPack,Wave, FLAC и т.д.; они сохранят звук без изменений, сэмпл за сэмплом, независимо от настроек кодера. Напротив, форматы с потерями, такие как MP3, предназначены для экономии места путем изменения звука тонкими, часто незаметными способами, даже при максимальных настройках кодера.
Высокое качество (Hi-Fi, домашнее прослушивание с лучшим размером файла):
Эти настройки VBR обычно дают прозрачные результаты. Звуковые различия между этими пресетами могут существовать, но они редки.
Очень высокое качество с максимальным размером файла:
-b 320 — альтернатива настройкам VBR, указанным выше.
Этот режим CBR максимизирует битрейт MP3 и общий размер файла. Дополнительное пространство может позволить сжать некоторые части аудио с меньшими потерями, но на сегодняшний день никто не дал результатов испытаний ABX, демонстрирующих, что воспринимаемое качество всегда лучше, чем самые высокие профили VBR, описанные выше.
Портативный (прослушивание в шумных условиях, меньший битрейт, меньший размер файла):
Очень низкий битрейт, небольшие размеры:
Для очень низких битрейтов, до 100 кбит/с, ABR чаще всего является лучшим решением. Используйте —abr (например, —abr 80).
—preset voice доступен только в интерфейсе командной строки и предназначен для совместимости. В настоящее время он сопоставлен с —abr 56-мм, что означает, что рекомендуется кодировать в моно и использовать ABR.
Понимание настроек битрейта
MP3 разделены на кадры, каждый из которых имеет определенный размер, выраженный в битрейте. Если битрейт каждого кадра одинаков во всем файле, то файл считается с постоянным битрейтом (CBR). В противном случае это переменная скорость передачи (VBR). LAME предлагает режимы кодирования CBR и VBR, а также специальный режим кодирования VBR, называемый ABR (средняя скорость передачи в битах).
VBR (переменный битрейт) настройки
VBR: режим переменной скорости передачи данных. Используйте режимы с переменным битрейтом, когда целью является достижение фиксированного уровня качества с использованием минимально возможного битрейта. VBR лучше всего использовать для определенного уровня качества, а не определенного битрейта. Окончательный размер файла для VBR-кодирования менее предсказуем, чем для ABR, но качество обычно лучше.
См. также: Что такое передискретизация?
В отличие от других MP3-кодеров, которые выполняют VBR-кодирование на основе прогнозов качества вывода, метод VBR по умолчанию LAME проверяет фактическое качество вывода, чтобы гарантировать, что всегда достигается желаемый уровень качества.
Также допускаются дробные значения с точностью до трех знаков после запятой, при этом 9,999 — это самое низкое качество.
Примечание. Параметр —vbr-new, который включил превосходный режим VBR в LAME 3.97 и некоторых предыдущих версиях, больше не требуется для LAME 3.98 и выше, поскольку теперь он является режимом VBR по умолчанию. Однако, если вы все еще используете LAME 3.97 или старше, вы должны добавить —vbr-new в командную строку, чтобы использовать этот режим.
Целевой битрейт и фактический типичный битрейт для каждого уровня качества VBR:
Если вам нужен предсказуемый битрейт (например, в потоковом приложении), используйте режимы ABR или CBR, описанные ниже.
Настройки ABR (среднего битрейта)
Компромисс между режимами VBR и CBR, кодирование ABR изменяет биты вокруг заданной целевой скорости передачи данных. Используйте ABR, когда вам нужно знать конечный размер файла, но при этом все же хотите предоставить кодировщику некоторую гибкость, чтобы решить, какие отрывки требуют больше битов. Вывод — это обычный файл VBR, совместимый со всеми MP3-плеерами, которые поддерживают VBR; ABR — это не особый тип файла, а стратегия LAME для создания VBR.
Важно: настройка ABR настраивается с 320 кбит/с до 80 кбит/с.
Настройки CBR (постоянный битрейт)
Кодирование CBR не эффективно. В то время как режимы VBR и ABR могут предоставлять больше битов для сложных музыкальных фрагментов и сохранять биты на более простых, CBR кодирует каждый кадр с одинаковой скоростью передачи.
См. также: Что такое частота дискретизации?
CBR рекомендуется только для использования в потоковых ситуациях, когда необходимо строго соблюдать верхний битрейт. За кулисами все еще есть некоторая изменчивость в битрейте благодаря использованию LAME функции резервуара битов формата MP3, но она гораздо менее гибкая, чем фактический VBR.
Важно: настройка CBR настроена с 320 кбит/с до 80 кбит/с.
Заметка
Все режимы и настройки, упомянутые в этом разделе, соответствуют спецификациям стандарта MP3, и полученные MP3-файлы должны воспроизводиться каждым декодером MP3, который соответствует стандарту. Если ваш декодер или устройство не воспроизводит MP3-файлы, созданные LAME, вините производителя или разработчика, а не LAME. До LAME 3.98 ключ —vbr-new включал новый режим VBR. Теперь это режим VBR по умолчанию. Старый режим доступен через —vbr-old. С точки зрения качества новый режим выглядит лучше старого, но сообщения об артефактах при использовании нового режима существуют. Несмотря на эти возможные проблемы, новый режим в настоящее время рекомендуется из-за увеличения скорости и качества, обеспечиваемого новым алгоритмом.
Resampling (ресемплирование)
Когда входная частота дискретизации превышает 48 кГц, LAME повторно изменит ее до максимальной частоты 48 кГц (максимум, поддерживаемый MP3). В режимах VBR с 7 по 9,999 и при битрейтах CBR ниже 104 кбит/с вход повторно дискретизируется до 32000, 24000, 22050, 16000, 12000, 11025 или 8000, в зависимости от целевого уровня качества или битрейта. Так как это требуется при повторной дискретизации, всегда применяется фильтр для удаления частот, превышающих половину частоты дискретизации. Приведенная выше информация о нижних частотах указывает, выполняется ли какая-либо дополнительная фильтрация.
Внутренний ресэмплер LAME не идеален. Если требуется повторная выборка, лучшие результаты (особенно при нацеливании на низкие битрейты) можно получить с помощью высококачественного преобразователя частоты дискретизации, такого как SoX или SSRC.
Несовместимость декодера Фраунгофера
Разные интерпретации неясной части спецификации MP3 привели к тому, что специфичная для Windows версия MP3-декодера Fraunhofer IIS не смогла правильно воспроизводить определенные MP3-файлы, созданные с определенными версиями LAME.
См. также: Что такое битрейт?
Чтобы продемонстрировать проблему, проблемный MP3 должен быть создан с LAME 3.97 или более ранней версии и должен содержать кадр с определенными параметрами и очень большим объемом данных, например кадр 320 кбит/с, который интенсивно использует бит резервуар. Декодером должен быть фильтр DirectShow l3codecx.ax версии 1.5.0 или ниже, используемый проигрывателем Windows Media в версиях Windows, предшествующих Windows Vista. Обновление безопасности для Windows XP и Server 2003, выпущенное в августе 2010 года, обновило этот фильтр до версии 1.6.0, которая может воспроизводить проблемные файлы MP3. Windows Vista поставляется с более старой версией, но проигрыватель Windows Media использует другой фильтр, и в более поздних версиях Windows этот фильтр вообще не используется.
Обходной путь был реализован в LAME 3.98.0 бета 1 до LAME 3.98.2 и в LAME 3.99 альфа 1, в результате чего кадры со скоростью 320 кбит/с были ограничены в том, какой объем битового резервуара они могли использовать. Это привело к потере впустую пространства, когда резервуар вырастет за пределы. В LAME 3.98.3 и более поздних версиях, а также в LAME 3.99 alpha 2 и более поздних версиях метод был изменен таким образом, что резервуар для долота не может расти выше предела.
VBR заголовок и тег LAME
LAME поддерживает стандарт де-факто добавления дополнительного кадра молчания к началу файлов MP3. Этот «заголовок VBR» или «информационный тег» предоставляет домашнюю страницу для точной информации о продолжительности звука и таблицу точек поиска. Это в основном для инженеров, работающих с файлами VBR. Декодеры обычно рассматривают кадр как информационный, а не воспроизводящий звук.
LAME использует формат Xing для этого заголовка и расширяет его, встраивая 20-байтовый «тег LAME» с дополнительной информацией:
Что случилось с «—alt-preset»?
В последних версиях LAME предусмотрены более удобные параметры командной строки, поэтому рекомендуется придерживаться одного из значений, описанных в тексте или показанных в таблице выше.
Например, следующие параметры командной строки будут выдавать одинаковые выходные данные:
—alt-preset insane
—preset insane
-b 320
—preset 320
—preset cbr 320
Итак, как мы уже видели, скорость работы Lame зависит не только от железа, но и от того, какую версию этой программы вам удалось найти на просторах интернета. Таким образом можно сказать, что «черные ящики» бывают разной черноты 🙂 В этом материала мы попробуем разобрать ящик под названием Lame и узнать, что у него там есть внутри интересного для нас (и вообще, стоит ли в него соваться).
К сожалению, авторы Lame сами распространяют только его исходные тексты, так что все версии для Windows являются в некотором смысле «самодельными» и уж конечно практически отсутствует полное и исчерпывающее описание, как конкретно была скомпилирована данная lame.exe. Пользователям *nix немного проще, поскольку принято считать, что проекты с открытым кодом в первую очередь развиваются с прицелом под эти ОС. Для них есть и специальный скрипт (на целых 400 KB) который может настроить оптимальные (по мнению авторов) параметры компиляции для данной платформы.
Если же вы используете ОС от компании Microsoft, то поиск может привести на mitiok.cjb.net и www.hot.ee/smpman/mp3. По этим адресам можно скачать уже скомпилированный файл кодека lame.exe. Кроме того, есть некая версия и на www.mp3-tech.org.
Что касается информации, о том, что же представляют собой эти программы, то ее не так уж и много. В первом случае это файл about, в котором написано следующее: This file was downloaded from http://mitiok.cjb.net/ mirrors: http://mitiok.ma.cx/ Compiled with icl 4.5 & nasm ACM compiled with MSVC 6.0 & NASM Please do not delete this file. exe & dll were compressed with UPX executable packer http://upx.sourceforge.net/ mitiok (kuts@atrus.ru)
Для второго варианта информации (в этот раз в файле file_id.diz) не больше:Lame 3.93.1 Stable Win32 executable Compiled by Intel C++ 4.5 compiler MMX, SSE & 3DNow! code optimizations using Netwide-assembler Downloaded from: http://www.hot.ee/smpman/mp3/
Третья версия в принципе не имеет какого либо упоминания о том, как, чем и кем она была создана.
При этом программы внешне практически одинаковы, при запуске все рапортуют о версии «LAME version 3.93 MMX (www.mp3dev.org)» (вторая правда дополнительно замечает, что она именно с сайта www.hot.ee/smpman/mp3).
(Здесь и далее если не указано противное, тестирование проводится на компьютере P4 2.4/SiS645/512 MB DDR333)
Как мы видим (по крайней мере, на нашей платформе) отличие в скорости есть. Между первыми двумя версиями оно не очень значительно, однако определенно существует (тест мы проводили несколько раз и разница в 1 секунду, что составляет 0,6%, сохранялась). Кстати, сами полученные mp3 файлы совпадают до бита, так что вопрос о качестве можно не поднимать. Третий участник значительно отстает от конкурентов. Файл получается у него на несколько десятков байт больше. Если сравнить его побайтово с предшественниками, то мы увидим, что отличия начинаются примерно с середины. Так что налицо и разная работа алгоритмов.
В отличие, например, от «счетных» программ, где результат (обычно) должен сохраняться вне зависимости от используемого компилятора, оптимизации и других параметров, в данном случае мы имеем дело с неоднозначным алгоритмом сжатия звука с потерями. Эта особенность вносит в процесс тестирования очень неприятный момент называемый «субъективность». Качество работы кодека не определяется численно, его нельзя объективно проверить, сравнить, понять, где лучше, а где хуже (это, конечно, не совсем верно, но суть проблемы отражает). Так что даже на примере уже этих, скомпилированных, кодеков мы сталкиваемся с вопросом «А может у более медленного варианта гораздо лучше качество?».
Поскольку мы сейчас рассматриваем кодек с точки зрения быстродействия, то вопрос качества оставим на его совести, поскольку вносить еще один неопределенный параметр в и так большой набор настроек было бы мягко говоря опрометчиво.
В принципе на этом можно и остановиться: мы нашли три варианта кодека, попробовали их в работе, выбрали аутсайдера.
Однако существование заметно более быстрого кодека GOGO (основанного на Lame) и туманные намеки об использовании различных оптимизаций (например, компилятором под SIMD или даже наличие руками написанных на ассемблере кусков кода), заставляет нас двигаться дальше и попробовать разобраться, откуда могли появиться найденные варианты и можно как-то еще улучшить скорость такого замечательного Lame.
Первым шагом, конечно, будет получение исходников. Архив объемом около 1МБ можно скачать, например на www.sourceforge.org. Конечно немного смущает, что программа так и остановилась на версии 3.93.1 в далеком (по меркам компьютерной индустрии) декабре 2002 года.
Однако, памятуя о том, что старое не означает плохое, смело распаковываем архив и начинаем изучать файлы readme и install. И здесь начинает светить слабый лучик надежды — оказывается, есть готовый Makefile для MSVC. Ну что ж, попробуем быстрый вариант — не залезая в его дебри просто скомпилировать проект на Microsoft Visual.NET 2003… Всего 59 секунд (на P4 2.4) и (о чудо!) в текущей директории мы видим файл lame.exe. С замиранием сердца пробуем его в работе… 3:13 на тех же установках. Ну что ж, неплохо для начала (забавно, но mp3 файл снова с точностью до бита совпадает с первыми двумя, что были получены ранее). Итак, теперь можно написать свой file_id.diz и смело выкладывать (не забывая файлы COPYING, LICENSE, README и USAGE из исходного дистрибутива) архив в сеть!
В общем, процесс получения своей версии lame.exe оказался не так уж и сложен. Однако мысль о том, что у кого-то получилось лучше, тревожит и заставляет углубиться в изучение Makefile.MSVC в котором можно найти очень много интересного.
Первым шагом по оптимизации является изменение компилятора на Intel (использовалась версия 7.1). Ух сколько полезло warningов… Ничего! Прорвемся! Итак, вторая попытка — 3:28. Мрачно, даже хуже, чем MSVC :(. Отметим, что mp3 файл уже другой. На слух разницы, правда, нет. Отличия начинаются не с самого начала, а где-то со смещения в 0x30000 байт (всего файл объемом около 7МБ, то есть только первые 2% — одинаковые).
Пробуем выбрать «заточку» на процессор на этапе компиляции (также, не меняя ничего в исходных файлах) — теперь для Pentium III. Получили уже 2:58. Что заметно лучше прошлых вариантов, но до лучшего времени в 2:46 не дотягивает. Отметим, что полученный файл также отличается от всех предшественников.
На следующем шаге, наконец, подправим немного сам Makefile.MSVC в связи с «последними решениями ВЦСПС», учитывая, что у нас есть процессор Pentium 4 (конечно эта версия на Pentium 3 и Athlon XP не будет работать). Просто добавляем еще один вариант настройки на процессор и…. Ура! Мы почти достигли конкурентов! Теперь у нас всего 2:51.
Однако поскольку опций в принципе у компилятора ну очень много то, теоретически, можно проверить все варианты, однако уж очень это грустное и не сильно перспективное занятие. Тем более что для разных процессоров могут быть оптимальными разные наборы. Хотя если скриптик написать… 🙂
Ну что ж, пожалуй, на компиляторах C можно закончить. Нам практически удалось достичь лучшего результата, однако только с использованием оптимизации под Pentium 4, что не очень корректно. Но остается еще один шанс — использование ассемблерных вставок. Для их использования необходимо скачать компилятор NASM, благо это всего 214 КБ в архиве.
Напомним, что до этого момента мы использовали только чистый C код и «играли» опциями компиляторов через командную строку при компиляции и немного меняли Makefile. Теперь же попробуем использовать и ассемблерный код. В Lame он используется несколькими способами. Первый (и самый простой и практически ясный) — это использование MMX для выполнения вспомогательных действий с одной из рабочих таблиц. Для этого нужно скомпилировать программу с использованием ассемблера NASM. Больше ни для чего MMX (имеется ввиду ассемблерный код, а не результат работы того же компилятора Intel) в Lame не используется.
Пробуем варианты MSVC+ASM и MSVC+ASM+MMX: 3:13 и 3:05.
Видно, что просто само по себе использование ассемблера ничего не меняет, поскольку в этом случае никакие процедуры на нем не используются. Однако первый шаг — замена одной из процедур на аналог, написанный на ассемблере с использованием MMX, дает дивиденды.
Смотрим далее и … находим файл на ассемблере и «3dn» в имени. Ура! Вот уже что-то. При ближайшем рассмотрении «это» оказывается процедурой FHT, написанной специально для набора команд 3Dnow!. Идем дальше… Находим также файлы fftfpu.nas и fftsse.nas, радуемся, что и про Intel не забыли. Однако дальнейшее исследование показывает, что эти файлы просто не используются! Строки в Makefile про них закомментированы с указанием «not yet coded». На этом месте стоит сильно расстроиться. Поскольку продвигаться дальше можно только очень медленно и осторожно. Дело в том, что для полного разбирательства придется лезть в исходники. А когда их много и они еще и не твои и практически без комментариев… Что-либо найти очень сложно. А про исправить я уже и не говорю.
Увы, чуда не произошло. Скорость работы MSVC версии от использования ассемблера практически не изменилась. Заметим, что при запуске этих модулей на Opteron программа рапортовала в том числе и о «3DNow! (ASM used)». Тем не менее, толку от этого никакого не было. На всякий случай попробуем отключить 3DNow! с использованием ключа командной строки, но и это не помогло. В общем такое поведение достаточно странно. Также интересным выглядит результат с компилятором Intel. На Pentium 4 этот вариант был самым медленным, а теперь он всего на 4 секунды отстает от лидера.
В случае использования компилятора Intel мы видим значительный эффект от использования оптимизированной процедуры на ассемблере. При этом оптимизация компилятором кода на C также дает значительный эффект.
Все полученные варианты lame.exe ведут себя практически случайным образом, так что совершенно непонятно, на чем и почему стоит остановиться.
В целом мы видим, что использование компилятора Intel положительно сказывается на быстродействии, особенно если использовать оптимизацию под SIMD различных процессоров. Что касается ассемблера, то в оригинале предусмотрено всего две возможности — MMX для вспомогательной процедуры (дает положительный эффект) и 3DNow! для FHT (что в наших примерах совершенно ничего не дало).
Увы, дальнейшее исследование очень осложнилось всякими глупостями, которые устроили авторы в исходниках. Например — индикация использования (или просто наличия, с первого раза не понятно) разных SIMD и ассемблерных вставок при «пустом» запуске lame.exe не производится. Обязательно нужно начать кодирование какого-либо файла.
К сожалению понять, что, когда и как используется просто не представляется возможным — уж очень там все запущено. Можно конечно раскопать, что же именно значит надпись «MMX», которая появляется время от времени при запуске программы (причем иногда с комментарием «ASM used»). Но… это уже совсем далеко от нашей темы.
Тем не менее, разобраться хочется, так что собираем все силы — и снова в бой!
Итак, для начала разберемся с названиями, версиями и прочей информацией, которую lame печатает при запуске. Начнем с первой строки: «LAME version 3.93 MMX (www.mp3dev.org)». Эта строка формируется одним из модулей и, к сожалению, не содержит третий номер подверсии (т.е. последнюю «1» в реальной версии 3.93.1). Видимо авторы решили, что это не сильно нужно. Так что точно узнать версию по готовому исполняемому файлу невозможно. Идем дальше и встречаем загадочную запись «MMX». В данном случае она показывает, что при сборке использовался ассемблер и одна из процедур оптимизирована под команды MMX.
Вторая строка, «CPU features», выводится на экран в момент запуска теста в работу и отражает текущее представление о наличии в процессоре различных наборов команд. При этом ограничения командной строки (опция –noasm <набор>) накладываются на реальные возможности процессора. Что в целом немного странно выглядит, поскольку кажется, что SSE в процессоре можно отключить простой опцией lame.exe :).
Теперь попробуем включить закомментированные варианты ассемблерной оптимизации под i387 и SSE. После тяжелой непродолжительной работы получаем файл, в котором предусмотрено использование этих ассемблерных вставок. Отметим, что поскольку в оригинале они не использовались, то, возможно, их работоспособность не гарантируется. (Кстати отметим, что в этих исходных файлах есть надписи, указывающие на их родство GOGO-no coda). К сожалению простого варианта выбора процедуры FHT не предусмотрено, поэтому вариант i387/FPU получается из SSE отключением последнего в командной строке при запуске Lame.
Мда… Результаты прямо скажем обескураживающие. Еще раз понимаем, что ничего не понимаем. Неприятное ощущение.
Отметим, что эти варианты генерировали файлы, отличающиеся по размеру от предшествующих участников. Тем не менее, на слух и по продолжительности они не отличались. Если же поставить lame параметр для генерации файла с CBR, то отличие в длине исчезает, но файлы, тем не менее, останутся разными по содержимому.
В общем нам удалось получить вариант кодека, который быстрее представленных в сети и работает на большинстве современных процессоров. Это версия Intel + ASM(FPU). Версии с оптимизацией под P3/P4 даже быстрее, однако менее универсальны. К сожалению вопрос об их реальном использовании остается открытым. Во первых, мы проверили скорость только на одной платформе. Во-вторых, только с одним вариантом настроек. Ну и в третьих — файл, который они генерируют, отличается от варианта кодеков от mitiok и smpman, так что есть потенциальная проблема с качеством.
Что касается представленных на разных сайтах готовых версий для win32, то можно предположить, что они получены с использованием ассемблерных вставок из комплекта поставки Lame (только MMX и 3DNow!), а для компиляции программ на C использовался продукт от компании Intel, который в свою очередь также использовал SIMD (видимо только MMX/SSE и с возможностью альтернативного исполнения на процессорах, их не поддерживающих).
Конечно, подобрать самый быстрый вариант из серии «Вот версию взять не последнюю, а прошлую альфу, и на компиляторе Borland и еще библиотечку ту спросить у Васи и на Атлоне тогда просто летает!» технически возможно. Но вот нужно ли это? 🙂
Тем не менее, мне не сильно жаль времени, потраченного на проведенные тесты. Обидно конечно, что не получилось красивого варианта «а вот мы круче!», где путем несложных действий с компиляторами и их ключами получить ускорение работы раза так в полтора-два, но… не в этом суть. По крайней мере получен бесценный опыт общения с OpenSource проектами 🙂 Пока единственным «красивым» вариантом использования таких тестов представляется работа со стандартным компилятором (возможно разным для разных ОС) и разумным минимумом оптимизаций.
PS Кстати, в сети можно найти и исходники GOGO-no-coda 3.12… и они даже компилируются MSVC+NASM. Как вы думаете, за какое время эта версия осилит наш пример? …. 0:31!
