Форум » Cсылки на программы и инструкции » Чем массово проверить mp3s на побитость » Ответить

Чем массово проверить mp3s на побитость

zencd: Вот когда мой плеер играет мп3шки, у него выскакивает сообщение что файл битый (mpeg resync). Во. А как бы пройтись по всему HDD и проверить его на такую побитость? Я не предлагаю выполнять сложный анализ спектра на предмет нахождения всхлипов (хотя тоже полезно), а просто ускоренно пройтись по фреймам с точки зрения плеера и выдать лог. Есть такой софт?

Ответов - 24, стр: 1 2 All

UberWolf: Тоже не отказался бы от такого софта, но, видимо, пока ещё никто не написал. Детект на mpeg resync есть в фубаре, выскакивает когда во время вопроизведения натыкается на такие места. Так что ещё один плюс для полного отслушивания поступающего материала.

zencd: во-во! как бы заставить его проиграть кучу музыки насколько можно быстро и составить отчёт

zencd: и кстати на всхлипы-обнаруживаемые-только-на-слух тоже нужен подобынй детектор правда любителям стиля clicks'n'cuts он не поможет но тут алгоритм непростой, а вот в 1м случае - элементарно всё сделать


zencd: Так что ещё один плюс для полного отслушивания поступающего материала отслушивать конечно нужно, но иногда просто не помнишь где выскакивали ошибки а так раз - запустил емул и можно плохие треки заменить (не совсем кошерно конечно)

UberWolf: zencd пишет: тслушивать конечно нужно, но иногда просто не помнишь где выскакивали ошибкиСразу ставлю примечание в каталоге с инфой о недочётах, их локации, чего и тебе настойчиво рекомендую делать. Также стараюсь и призываю ко всем - сообщать о найденных дефектах тому, от кого был получен альбом. zencd пишет: во-во! как бы заставить его проиграть кучу музыки насколько можно быстро и составить отчёт Ну, по сути дела, очень банально - кидаешь весь проверяемый материал в плейлист, запускаешь воспроизведение и жмешь на клавишу, отвечающую за seek до появления консоли с ошибкой, затем отмечаешь что за ошибка и где, и продолжаешь жать seek... Так, возможный способ :) если действительно вдруг понадобилось в относительно короткие сроки попытаться выявить mpeg stream error'ы. Ещё раз повторюсь - лучше пытаться отслушивать весь материал, т.к. могут быть иные звуковые дефекты, которые выявляются только при прослушивании.

Bete_Noire: 2 zencd Посмотри вот эти: _http://www.geocities.com/mp3utility/MP3Utility172.zip (127 kb) _http://141.68.102.149/%7Eshivan/MP3Test_v1.5.1.151.exe (679 kb)

UberWolf: Bete_Noire А описание есть? Не хочется сливать кота в мешке :)

Wild User: mp3Utiliti - отличная штука! Натравил на винте на 15 DVD, через несколько минут получил пару альбомов, где есть треки с помехами. Указывается временнОе положение помехи в треке. Послушал в плеере - точно, в этом месте глюки. В отличие от второй проги - бесплатная и нагляднее показывает путь к трекам (альбомам). У второй программы настроек побольше будет но она дольше и работает. Не очень удобно определять какой трек к какому альбому относится (через контекстное меню). Да и "пилюлю" пришлось поискать...

Die Hard: Запустил mp3Utiliti, проверил ~10Gb. Забраковал два трэка. Посмотрел, что имеем: 1-й трэк. Винамп показывает длительность песни 33:50, вместо реальных 5:38, во втором 30:02 вместо 5:00. В свойствах обоих файлов показывает 32kbps/32Khz/2Ch вместо 192kbps/44.1KHz/js остальных файлов на альбоме. Получается, что заголовок в обоих файлах битый, или что? Хотя, тот-же Tag&Rename на файлы не ругается.

UberWolf: Да, MP3Utility вещь архинужная для каждого коллекционера мп3.

zencd: Bete_Noire, спасибо за ссылки!

Bete_Noire: пожалуйста. рад, что пригодились

ahv: наткнулся вот, правда сам не проверял: http://www.foobar2000.org/components/index.html последний компонент (File Integrity Verifier)

zencd: ahv, и тебе спасибо! я как раз пользуюсь фубаром на тестовом альбоме выдал те же ошибки, но рассказал о них в терминах байтов :) что чуток неудобно

heine: возникает вопрос. насколько опасны и критичны обнаруживаемые MP3Utility sync errors? иногда в тех местах где он их находит практически и не слышно никаких глюков (особенно если с винила оцифровано)... хотя с другой стороны зачастую все-таки можно различить еле заметный щелчок (на к-ый без MP3Utility вряд ли и обратил бы внимание)... но так ли уж критичны подобные артефакты для мп3... ведь формат по определению lossless

Wild User: heine пишет: насколько опасны и критичны обнаруживаемые MP3Utility sync errors? ИМХО Опасность и критичность зависит целиком от представления о них слушателя. Программа просто ищет и находит ошибки синхронизации, указывая величину этой рассинхронизации. Если ты в состоянии переварить небольшой щелчок, а тем более мало- или вообще не заметные на слух повреждения, то некоторым даже мысль об этом может показаться кощунственной. Отсюда и понимание критичности... heine пишет: зачастую все-таки можно различить еле заметный щелчок Напротив названия файла программа указывает время, где было найдено повреждение. В плеере легко найти это место и проверить на слух. heine пишет: ведь формат по определению lossless Lossless - формат БЕЗ ПОТЕРИ КАЧЕСТВА и мп3 к таковым не относится. Было бы правильнее писать - LOSSY.

zencd: насколько опасны и критичны обнаруживаемые MP3Utility sync errors? чувак! ты послушай и сам решай - здесь то что спрашивать.. иногда незаметны, иногда заметны isn't?

UberWolf: Как показал мой личный опыт: 1) звуковой дефект есть не всегда, но этот случай всё же менее распространённый, чем обратное; 2) неприятное - MP3Utility находит не все места с ошибками.

heine: Wild User heine пишет: Lossless - формат БЕЗ ПОТЕРИ КАЧЕСТВА сорри за лослесс :) ближе к ночи писал, видимо совсем уже голова работать перестала... я именно и хотел написать lossy (mp3 etc) в противовес lossless (ape etc.) zencd речь о том, могут ли такие ошибки прогрессировать... хотя думаю вряд ли... интересно было бы послушать человека к-ый просветил бы нас по поводу природы и так сказать сущности sync error... Т.Е. ЧТО ЭТО ВООБЩЕ ТАКОЕ, классификация и т.д.

ahv: Sync error means that at a place where a frame header should be (that is immediately after the previous frame) none is found by the decoder. In most cases the cause are missing bytes in the frame immediately before the error, so that the next header or a part of it is part of the flawed frame. This byte shift either lets the decoder skip or mute this frame, or an audible error (blip or so) occurs. After this frame there is no frame header, and the decoder has to seek for the next bit pattern that looks like a valid header. Actually it should look for 3 valid headers & frames in sequence before being sure the resynchronization was successfull. When downloading files there may be transmission errors, therefore it is not a bad idea to zip MP3s even if this has no benefit sizewise. But errors will be detected when unpacking the zip. Also interrupted and resumed transfers sometimes show errors, or at least until several years ago I noticed this. Nowadays the resume algorithms seem to be good. http://www.hydrogenaudio.org/forums/lofiversion/index.php/t41421.html



полная версия страницы