Доступен релиз свободного редактора звука Audacity 3.0.0, предоставляющего средства для редактирования звуковых файлов (Ogg Vorbis, FLAC, MP3 и WAV), записи и оцифровки звука, изменения параметров звукового файла, наложения треков и применения эффектов (например, подавление шума, изменение темпа и тона). Код Audacity распространяется под лицензией GPL, бинарные сборки доступны для Linux, Windows и macOS...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54777
На gtk4 перевели уже?
Это wxgtk.
> Audacity 3.0Кто объяснит, почему эта штука в KDE смотрится ТАК крипово? В 100 раз хуже, чем другие приложухи на гтк.
WxQt пилите -- будет норм. Насколько я знаю, gtk2 в кде всегда прекрасно выглядит, не отличить. Может быть, не хватает пакетов интеграции? Или гтк доломали? Раньше 2 и 3 были отдельно, теперь, как я слышал, там 2 от 3 зависит?
>Кто объяснит, почему эта штука в KDE смотрится ТАК крипово?она везде смотрится не модно, зато работает, как... (много эпитетов)
она и в гноме крипово всегда выглядела
Оно с wxGTK собранным с GTK3 то нормально не работает. Официальные сборки с GTK2.
https://github.com/audacity/audacity/issues/639
Ох, блин. А как же hidpi и прочие блага современного мира? (про wayland не заикаюсь, его бы тоже неплохо, но там и обходные пути есть). С этим на gtk2 грустно..
Нормально работает, если с wxGTK 3.1
Запускал в sway без XWayland. Полет нормальный.
Какая наглость!
???
Игра слов.
Audacity
Бинарники на SourceForge выложить не осилили?
> Audacity is no longer at SourceForge.
И на github тоже не осилили
https://github.com/audacity/audacity
и прочитать не осилил
ссылка на Windows версию не рабочая
Нормальные ссылки для MacOS и Windows. Там еще приписка есть:Audacity is no longer at SourceForge.
Audacity can be downloaded via AudacityTeam website instead: http://www.audacityteam.org/download/
вот и напишите рабочую раз no longer
Так автор новости оперативно исправил эту часть. Сами взгляните на новость.
А highDPI на windows так и не поддерживает
notabug
Oculus rift тоже до сих пор не поддерживается.
Мсье знает толк в извращениях!
64-х битные версии так и не сделали для виндовс
Сидят сиськи мнут. Неохота.
А зачем? Вы ему 5-гигабайтные вавки в оперативу скармливаете? Есть же настраиваемый размер кэша. Хотя у меня даже 3-я Audition (32 бита) умеет как-то пихать более 2 Гб кэша в ОЗУ.
Ну да - лень. Две версии собирать и прочее.
Под macOS вон выкинули 32 бита и 64 битная версия появилась.
>все компоненты проекта теперь сохраняются в одном файлеИз разряда "давно пора"!
Да что-то плохая идея как по мне.Разбираться в таком формате будет проблематично, особенно если что-то где-то поломается.
Да и вопросов с эффективностью работы масса.
>Предложен новый формат для сохранения проектов - ".aup3". В отличие от ранее применяемого формата, все компоненты проекта теперь сохраняются в одном файле, без разделения на файлы с данными и файл с параметрами проекта (подобное разделение приводило к казусам, когда копировали только файл .aup и забывали перенести данные). Новый формат .aup3 представляет собой базу в формате SQLite3, содержащую все ресурсыОпять деструктивный или уже нет?
> представляет собой базу в формате SQLite3, содержащую все ресурсы.Сохранять вавки в БД. Куда катится этот мир? :)
Катится туда->(0)
по любой из последних теорий он катится именно туда. как при сверхплотном схлопывании, так и при сверх разряженном расширении. все должно вернуться обратно к форме существования чистой энергии. ну это так в образовательных целях. а мир и правда г**но.))))
Это в какой же такой "форме" чистая энергия будет собрана и статически находится в одной точке??... При нынешнем расширении энергия в виде фотонов всё равно рассеивается и, видимо, уже навсегда потеряна для "Нового Большого взрыва"... как ты живешь в этом мире и что привносишь - таким он и становится - всё зависит от нас и конкретно - от тебя...
Кстати да, почему не стандартный для таких целей zip?
Потому что сложнааааааа.Я вот тоже не понимаю - зачем для сохранения конфигурации и бинарей использовать реляционную базу данных? Зачем гвозди забивать микроскопом?
Потому что реляционная база данных даёт забесплатно эффективную реализацию чтения с внешнего накопителя, которая будет оставаться эффективной в широком диапазоне случаев. Рандом-акцесс, последовательное чтение, разнообразные выборки данных и даже простейшая обработка, и всё может быть не на топовой достижимой производительности, но во всяком случае не сильно хуже. Будешь писать руками, запросто можешь получить на порядок хуже, и потом замучаешься ещё под накопители разных типов писать свои драйвера и тестировать их везде. Зачем изобретать велосипед?
Контейнер matroska? Нет, не слышал.
У всех контейнеров все отвратительно с произвольным доступом, а у некоторых еще и с синхронизацией дорожек. Для редактора это, как ты понимаешь, критично.
> Контейнер matroska? Нет, не слышал.Контейнер matroska за тебя будет маппить файл в память, или делать read'ы, грамотно расходуя оперативку, чтобы кешировать куски данных и по возможности не читать их повторно?
А в чем прикол делать работу операционки самому? Там как раз уже был дисковый кэш и все такое. Но, конечно можно сожрать память второй раз, под свой кэш...Хотя вот конкретно матрешка не сильно удобна в парсинге для in-place перетряхивания, не для этого она.
> А в чем прикол делать работу операционки самому? Там как раз уже
> был дисковый кэш и все такое. Но, конечно можно сожрать память
> второй раз, под свой кэш...Ядро кеширует диск в своей ядерной памяти. Но чтобы оттуда извлечь данные тебе надо сделать как минимум два сисколла -- lseek и read. Сисколлы -- это дешевле чем чтение с диска, но существенно дороже, чем доступ к памяти в адресном пространстве процесса. Поэтому, скажем, stdio.h с его FILE существует с момента появления unix. Но FILE -- это последовательный доступ. Тебе же нужен random, значит и кеширование/буферизация должны быть сложнее.
> Потому что реляционная база данных даёт забесплатно эффективную реализацию чтения с внешнего накопителя, которая будет оставаться эффективной в широком диапазоне случаев. Рандом-акцесс, последовательное чтение, разнообразные выборки данных и даже простейшая обработкаЧто-то сомнительно для подобного. Изображения, аудио, видео никто так не суёт же.
Да и там наверно BLOB поля BLOB полями погоняют?
> Да и там наверно BLOB поля BLOB полями погоняют?Не знаю, я не заглядывал внутрь. Если бы мне захотелось pcm засунуть в sql, то я бы начал с экспериментов, когда каждый сэмпл отдельной строкой таблички.
> Что-то сомнительно для подобного. Изображения, аудио, видео никто так не суёт же.
Естественно, зачем ты будешь хранить непожатый pcm-звук, когда его можно пожать? Но хранить его непожатым для редактирования, мне кажется, самое то, что надо. Потому как если жать, то всё равно придётся loseless использовать, этот loseless будет сжимать не на порядки, а в разы, то есть выигрыш не запредельный, а вот замедление доступа заметно будет. Уход от этого замедления, может ведь открыть простор для дальнейших оптимизаций потребления оперативки -- можно вообще хранить обрабатываемые данные на диске, доставая их оттуда, обрабатывая, и складывая обратно. При этом, некоторые операции вообще окажутся примерно бесплатными: вырезать кусок из середины или вставить его, например. С последовательным файлом тебе придётся двигать данные в файле с одного смещения на другое, с pcm в sql можно обойтись DELETE'ом или INSERT'ом. Не совсем правдо очевидно, как при этом не потерять порядок -- понятно, что индексами можно, но как бы так чтоб без переиндексации половины сэмплов в файле обходиться? Но опять же, sql тут даёт тебе возможности хранить в отдельных табличках дополнительные данные, например, список непрерывных диапазонов сэмплов, каждый из которых задан диапазоном id'ов из PRIMARY KEY, который отсортирован по времени от начала трека. И не просто хранить, но ещё и иметь возможность эффективно извлекать данные основываясь на этом. Меняя один формат на другой за десять минут, чтобы прогнать через бенчмарки и посмотреть, не будет ли быстрее.
> Не совсем правдо очевидно, как при этом не потерять порядок -- понятно, что индексами можно, но как бы так чтоб без переиндексации половины сэмплов в файле обходиться?По принципу LinkedList, иметь поле NextId и обновлять это поле у предыдущего чанка.
Но сама идея хранить каждый сэмпл отдельной строкой таблички IMHO безумно неэффективна.
>> Не совсем правдо очевидно, как при этом не потерять порядок -- понятно, что индексами можно, но как бы так чтоб без переиндексации половины сэмплов в файле обходиться?
> По принципу LinkedList, иметь поле NextId и обновлять это поле у предыдущего
> чанка.Там разные способы могут быть. Можно и дерево организовать. Что лучше зависит от паттернов использования.
> Но сама идея хранить каждый сэмпл отдельной строкой таблички IMHO безумно неэффективна.
Не знаю, я не пробовал. Можно не отдельные сэмплы, а блобами по нескольку сотен/тысяч сэмплов. Но сложнее будет выискивать сэмпл по заданному смещению в миллисекундах. Сложно судить, не имея опыта возни со схожей задачей.
> Не знаю, я не заглядывал внутрь.Но всё равно знаешь лучше всех, так?
>> Не знаю, я не заглядывал внутрь.
> Но всё равно знаешь лучше всех, так?Естественно, а тебе что завидно что ли?
> я бы начал с экспериментов, когда каждый сэмпл отдельной строкой таблички.Пристрелите его кто-нибудь, чтобы не мучался... программирование явно не его конек.
https://www.sqlite.org/fasterthanfs.html
> даёт забесплатно эффективную реализацию чтения с внешнего накопителяТы свои акции МММ уже продал или всё ждёшь дивидендов?
Такакая эффективная, что NoSQL хранилищам на порядок сливает по скорости.
> Такакая эффективная, что NoSQL хранилищам на порядок сливает по скорости.Да-да. Точно. И какую из NoSQL субд им следовало использовать? Что там есть встраиваемого, заточенного под их нужды?
Что сделали - то сделали, бесплатно же, и так сойдёт. Возможно, современные процессоры без проблем тащат сборку строкового запроса на стороне приложения и его парсинг и исполнение на стороне драйвера бд 44100*2 раз в секунду на каждый сэмпл, не знаю, посмотрим.
Вообще-то запрос парсится не на каждый сэмпл, не надо преувеличивать. В худшем случае он парсится один раз на выполнение запроса, вне зависимости от того, скольких строк этот запрос касается. В случае использования хранимых процедур, он парсится один раз за время работы приложения.
Каким встраиваемым NoSQL сливает? А то хотелось бы, чтобы побыстрее, ага.
> Каким встраиваемым NoSQL сливает? А то хотелось бы, чтобы побыстрее, ага.MMKV например https://www.fatalerrors.org/images/blog/553873cf5efc0635603c...
Всего-то в ~100 раз быстрее.
>> Каким встраиваемым NoSQL сливает? А то хотелось бы, чтобы побыстрее, ага.
> MMKV например https://www.fatalerrors.org/images/blog/553873cf5efc0635603c...
> Всего-то в ~100 раз быстрее.Хаха. Что это за графики? Это они в какой ситуации меряли? Что у них за диск был? Что за ОС? Как они меряли? А что будет, если я прочитаю каждый второй int из файла? Каждый десятый? А если я захочу прочитать только те инты, которые делятся на три? А конкретно на тех задачах, которые встают перед audacity, как он будет справляться с ними?
Все эти графики вызывают серьёзное подозрение, примерно такое же, как и доказательства того, что java быстрее C++, которые 20 лет назад было популярно публиковать. Может и быстрее в том случае, в котором проводилось тестирование, но даже если и так, то это скорее всего совершенно нереалистичный и неинтересный случай.
Что-то я не понимаю с чего вы считаете будто бы считать бинарные блобы из SQLite эффективнее чем чем читать их как файлы стандартными средствами Ос?
> Что-то я не понимаю с чего вы считаете будто бы считать бинарные
> блобы из SQLite эффективнее чем чем читать их как файлы стандартными
> средствами Ос?Потому что я не считаю так. Речь ведь не о том, чтобы просто считать бинарные блобы, речь о приложении, которое работает с данными в файле. А работа с файлом может включать в себя не только последовательное чтение. Вот как ты будешь читать из файла? То есть, во-первых, ты будешь читать из файлА или из файлОВ? Наверное, всё же первое? Один файл и там поток сэмплов, так? Тогда, если тебе нужен блоб оттуда, что ты делаешь? lseek+read, так? В идеале хотелось бы так, потому как этот метод вряд ли чем-либо порвать удастся.
Но теперь прикинь, пользователь тыкает в интерфейсе и говорит "вот сюда я хочу вставить кусок звука". Что происходит на диске в ответ? А там паника, потому как стандартные средства фс не умеют расширять файл вставляя в середину кусок. Значит что надо делать? Вариант номер раз -- не сохранять почём зря, в надежде что приложение не упадёт, и электрик рубильником свет во всём доме не вырубит, и что промежуточный достигнутый пользователем результат не будет потерян. Вариант номер два -- читать с диска и перезаписывать полфайла. Вариант номер три -- разбить единый поток на маленькие блобы, и если что-то вставляется в середину, реально дописывать это в конец файла. Но тут тебе уже надо хранить в каком-то виде отображение времени от начала записи в смещение на диске. И это значит, что ты начал переизобретать базу данных и создавать её наколенную реализацию. И получится ли у тебя быстрее чем у sqlite -- это большой вопрос.
Эффективное же хранилище на жёстком диске, может открыть простор для того, чтобы а) сохранять промежуточный результат после каждого изменения, б) не хранить в памяти ВСЁ, хранить всё на диске, читая оттуда по мере необходимости, а это значит, что можно вместо сотен мегабайт или гигабайт ОЗУ под данные жрать ну, десятки мегабайт, наверное. Оу, это будет медленнее, чем всё хранить непосредственно в адресном пространстве процесса, но ровно до тех пор, пока у ОС достаточно оперативки: как только оперативка кончится, ОС начнёт свопить, и вот тут твоя производительность пойдёт лесом, в то время как вообще-то, если заточить приложение на хранение данных на диске, с чтением в память только нужного, то можно даже при нехватке оперативки под все данные, работать пускай не быстро, но и не запредельно тормозно. При этом, ежели у ОС достаточно свободной памяти, она закеширует содержимое диска, и будет не настолько уж и медленнее. Но сделать так, чтобы это "не настолько уж и медленнее" обеспечивало бы пристойную скорость работы на всём спектре железа которое используется под persistent storage и на всех ОС, на которых работает приложение -- это задача не для слабонервных, это задача для разработчиков бд.
Я думаю аудиоредакторы работают немного не так.Оно читает по заданной временной схеме данные из файлов, и через фильтры соединяет их в один поток.
Исходные файлы + схема редактирования + фильтры и есть проект.
Вставлять в середину ничего нигде ненужно.Работа же с файлами, это основа, ничего такого в этом нет, это второе чему учится программист после хеллоу верда.
Да, можно семплы в базу данных запихать, только преимуществ кроме инсерта, который аудиоредактору ненужен, я не вижу.
И это явно не то, что делает аудиосити. Насколько я понял, оно просто конфиг вместе с файлам-блобами фигачит в базу.
> Вставлять в середину ничего нигде ненужно.Но я же могу вставить звук в середину трека в аудасити. Вот реально -- ты поставь его и посмотри.
> Работа же с файлами, это основа, ничего такого в этом нет, это
> второе чему учится программист после хеллоу верда.Да, именно поэтому, редко кто берётся писать движок для базы данных, и ещё реже кому удаётся написать хороший. Потому что это слишком просто: этому учат на втором уроке информатики в школе.
Работа с файлами -- это ппц как медленно, пока читается сектор с жёсткого диска, можно сотню sql-запросов распарсить, и сотню _умных_ планов чтения выработать. Если умный план чтения позволит снизить время чтения на 20%, то ты в выигрыше по времени.
> Работа с файлами -- это ппц как медленно,А что, базы данных не с диска берут данные? В памяти кэшируют? А приложение само не может закэшировать в память этот файл, если ему это так надо?
И вообще - давно аудиоредактору нужна такая скорость чтения? У него тысячи запросов в секунду чтобы звук в середину трека вставить?
"SQLite blobs have an absolute maximum size of 2GB and a default maximum size of 1GB"Рано или поздно кто то наткнется
> "SQLite blobs have an absolute maximum size of 2GB and a default
> maximum size of 1GB"
> Рано или поздно кто то наткнетсяА смысл для аудасити хранить там блобы такого размера? Порезать помельче и уложить. По килобайту, по десять килобайт, но всяко не гигабайтами.
А что конкретно в зип паковать собрался то ?
С десяток файлов, в т.ч отдельные жирные бинари и какие-то файлы настроек, которые, прежде чем читать/писАть, ещё и распаковать куда-то надо ?Когда речь о хранении настроек, подход со встраиваемой БД очень даже удобен:
Нормальные чтение/запись/какие-то запросы над данными и возможность хранить очень много разных данных( от бинарей и до текстовых строк/массивов/итп ) и все данные структурированно хранятся в одном файле, притом структура эта не самопальная, а общеизвестная
Зип работает довольно прозрачно.
В данном случае просто распространенный формат с бонусом в качестве сжатия.
Ничего кардинально не изменит, решит проблему с хлебушком непонимающим что их проект лежит в папке а не одним файлом.SQL тут все-же немного оверинжиниринг, что не есть хорошо.
> SQL тут все-же немного оверинжиниринг, что не есть хорошо.Пара файлов исходников скулЯ, которые неплохо встраиваются и имеются как само-собой разумеющееся в тех же мобильных ОСях + файл БД, в который структурированно затолкано все что требуется..
Против кучи отдельных файлов, которые затолканы в архив, который, прежде, чем даже начать работать с параметрами( чтение и, тем более, запись ), нужно еще как-то куда-то распаковать.
Ну и где тут "оверинжиниринг" ?Кстати, ту БД ничто не мешает сжать, но едва ли это поможет, когда речь об уже сжатых медиаресурсах - там хорошо, если архив жирнее не выйдет.
> нужно еще как-то куда-то распаковатьА SQLlite не надо ни в какую-то ОЗУ считывать, и оно как-то само предоставить крутое доступ к бинарным полям или как вообще?
> А SQLlite не надо ни в какую-то ОЗУ считывать, и оно как-то
> само предоставить крутое доступ к бинарным полям или как вообще?Типо файлы после распаковки не надо открывать, парсить и.. ?
В случае с архивом прибавляется еще один жирный этап, а если исключить что-то типа встраиваемой БД, то еще прибавляются эпически костыли в виде полусамопальных подобий БД.
С бинарными данными типа сжатых медиа заморачиваться над архивацией - верх глупости, поскольку это не текстовые исходники и сжимаются они почти_никак, но сжатие-распаковка требуют времени ЦП, требуют ОЗУ и, главное, требуют какого-то времени.
А что, если "вдруг" какие-то данные сохранить захотелось ? -Это, помимо записи в файлы( вне зависимости, стандартную встроенную БД вроде sqlite или самопальное подобие БД применять ), потребует еще и генерации архива, не итак ли
Вообще ни о чём. Как буд то тебя кто заставляет сжимать данные.
> Вообще ни о чём. Как буд то тебя кто заставляет сжимать данные.Использовать зип чтоб не_сжимать данные ? -Мистер знает толк в извращениях и переусложнениях
да нет никаких переусложнений, я вообще выше про что-то тар подобное писала сабж это прям - затолкали сумели.
Ненужно. Из зипа можно читать напрямую.
https://www.sqlite.org/appfileformat.html
Зазипуй пару гигабайт аудио -- узнаешь :)
А зипы - нормальная идея в отличии от блоба. Что-то я не припомню чтоб скулит мог селектить в поток.
Да ладно зипы — тар образное что-то, всё же на аудио налезет.
А так тут пишут, что SQLite всё в ажуре сделает, прям не налезает.
Имеешь дело с более тяжёлыми оракл продуктами ака майсиквел и оракл сикуэль. Ну есть у меня ячейка картэжа блобная типа изображений, и то как-то просто засаживаешь по типу «ну раз огромная БД есть, я тут пристрою».
А тут просто так и сяк. Выглядит как какой-то студенческий проект, ну как смогли так засадили, всё равно несерьёзно.
Прокудин, ты сникерс сегодня не съел?! В zip есть разные варианты сжатия. Включая NONE!
И чо? Это всё равно подразумевает предварительную распаковку во временный файл, что означает лишние тормоза и распухание.
> бинарные сборки доступны для Linux, Windows и macOSОфициальных бинарных сборок для линукса нет, только исходники.
Долгих лет проекту
Прозвучало как реквием.
Это тост. Не чокаясь.
> Это тост. Не чокаясь.И стоя.Не закусывая.
В черных, наглухо застёгнутых костюмах.
> В черных, наглухо застёгнутых костюмах.Под дождём.Осенью.
Люблю такое"1progs.ru
Audacity 3.0.0 RC6 на русском крякнутый + lame_enc dll - скачать последнюю версию программы для Windows 10 или более ранних версий можно ..."
Точно крякнутая ?
Не хочу крякнутую, может кто кейгеном поделится? ;)
На гитхабе скачай.
А нахрена это шаманство с lame mp3, когда кодек уже пару лет ушёл в общественное достояние?
Пофиг, во что сохраняет, пофиг даже как выглядит. Главное - чтобы оно для начала функции выполняло. Надеюсь, фильтры поправили и звона больше не будет.
aup3 люто плюсую
Сохранение в .aup3 — какой-то маразм. Закинул свой подкаст. Файл 20 метров opus. Сохранил в .aup3 — файл 465 метров. Смысл????
Так ведь он же разжимает сжатое аудио в wav, чтобы можно было редактировать
Это же аудиоредактор
Если он умеет разжимать сжатое аудио, то вот пусть бы и разжимал при открытии проекта. А в самом проекте можно было бы хранить "как есть".
А то смысл какой от того, что оно разжало 20 метровый лосси файл в 400 метровый и в таком виде его хранит?
А ты точно его как редактор используешь? Или только как плеер?!
Как плеер он откровенно слаб. Как редактор х.з.
Использовать редактор в качестве плеера - это утонченно :). Так то еще в CAD'е можно попробовать пикселарт рисовать.
Тот же Ardour примерно так и делает. А вообще это называется недеструктивное редактирование.
Создай проект Ardour, импортни .flac, сохрани проект, внимательно посмотри в папку 'interchange/{название проекта}/audiofiles'.
Насколько я помню Ardour имеет напрямую работать с !wav файлами. А вообще я немного про другое сказал, я говорил про недеструктивное редактирование.
> Насколько я помню Ardour имеет напрямую работать с !wav файлами.Ты помнишь неправильно :)
Точно. Задумайся, что в твоём вопросе не так, перечитав подряд два предыдущих комментария.
Там вон рядом почти в цель попали, упомянув недеструктивное редактирование.
Впрочем это не тот вопрос, ради которого скоро коммент-баттл устраивать.
В теории он не должен держать весь файл в памяти при этом, он может лежать на диске. А если в память деклдировать каждый раз, придётся где-то брать десятки и сотни гигабайт памяти на этот wav, либо убивать диск постоянной записью терабайт мусора (что тоже не быстро), а диски сейчас пошли что 5 раз запишешь и на свалку отправлять пора.
Это не редактор файлов Opus, это звуковой редактор.
Ага. Но последовательность - сначала импортнуть (и при этом разжать) а только потом редактировать - сохраняется. Смекаешь?
А вы jpeg так же редактируете?
А ты еще ничего не поредактировал. Но файл у тебя в 10 раз уже вырос.
Нередко пользуюсь Audacity для записи и несложной обработки.
На мой взгляд - весьма несложный и весьма удобный инструмент.
Спасибо ребятам за работу!
Посмотрел...
Как был неуклюжий программистский интерфейс с дурацкими хоткеями и биндингом мыши 5 лет назад, так и остался. Продолжу сидеть на старом-добром Audition 3.
сиди. я как-то плевался, плевался, а потом понадобилось: шумы, подкасты, свести то, да се и он меня очаровал..
где-то читал что Burial делал музыку в Audacity
