Отправлено: 07.09.06 06:50. Заголовок: Чем массово проверить mp3s на побитость

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

Я не предлагаю выполнять сложный анализ спектра на предмет нахождения всхлипов (хотя тоже полезно), а просто ускоренно пройтись по фреймам с точки зрения плеера и выдать лог.

Есть такой софт?

 Отправлено: 07.09.06 08:15. Заголовок: Re:

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

 Отправлено: 07.09.06 11:02. Заголовок: Re:

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

 Отправлено: 07.09.06 11:57. Заголовок: Re:

и кстати на всхлипы-обнаруживаемые-только-на-слух тоже нужен подобынй детектор
правда любителям стиля clicks'n'cuts он не поможет

но тут алгоритм непростой, а вот в 1м случае - элементарно всё сделать

 Отправлено: 07.09.06 12:07. Заголовок: Re:

цитата:

Так что ещё один плюс для полного отслушивания поступающего материала

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

 Отправлено: 07.09.06 14:57. Заголовок: Re:

zencd пишет:

цитата:

тслушивать конечно нужно, но иногда просто не помнишь где выскакивали ошибки

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

цитата:

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

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

 Отправлено: 09.09.06 10:33. Заголовок: Re:

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)

 Отправлено: 10.09.06 12:50. Заголовок: Re:

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

 Отправлено: 10.09.06 15:34. Заголовок: Re:

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

 Отправлено: 11.09.06 08:48. Заголовок: Re:

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

 Отправлено: 11.09.06 19:06. Заголовок: Re:

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

 Отправлено: 13.09.06 14:42. Заголовок: Re:

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

 Отправлено: 13.09.06 17:20. Заголовок: Re:

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

 Отправлено: 14.09.06 10:01. Заголовок: Re:

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

 Отправлено: 15.09.06 01:42. Заголовок: Re:

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

 Отправлено: 06.10.06 17:55. Заголовок: Re:

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

 Отправлено: 06.10.06 18:35. Заголовок: Re:

heine пишет:

цитата:

насколько опасны и критичны обнаруживаемые MP3Utility sync errors?

ИМХО
Опасность и критичность зависит целиком от представления о них слушателя. Программа просто ищет и находит ошибки синхронизации, указывая величину этой рассинхронизации. Если ты в состоянии переварить небольшой щелчок, а тем более мало- или вообще не заметные на слух повреждения, то некоторым даже мысль об этом может показаться кощунственной. Отсюда и понимание критичности...

heine пишет:

цитата:

зачастую все-таки можно различить еле заметный щелчок

Напротив названия файла программа указывает время, где было найдено повреждение. В плеере легко найти это место и проверить на слух.

heine пишет:

цитата:

ведь формат по определению lossless

Lossless - формат БЕЗ ПОТЕРИ КАЧЕСТВА и мп3 к таковым не относится. Было бы правильнее писать - LOSSY.

 Отправлено: 06.10.06 20:00. Заголовок: Re:

цитата:

насколько опасны и критичны обнаруживаемые MP3Utility sync errors?

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

 Отправлено: 06.10.06 21:41. Заголовок: Re:

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

 Отправлено: 07.10.06 06:26. Заголовок: Re:

Wild User heine пишет:

цитата:

Lossless - формат БЕЗ ПОТЕРИ КАЧЕСТВА

сорри за лослесс :) ближе к ночи писал, видимо совсем уже голова работать перестала... я именно и хотел написать lossy (mp3 etc) в противовес lossless (ape etc.)

zencd
речь о том, могут ли такие ошибки прогрессировать... хотя думаю вряд ли...

интересно было бы послушать человека к-ый просветил бы нас по поводу природы и так сказать сущности sync error... Т.Е. ЧТО ЭТО ВООБЩЕ ТАКОЕ, классификация и т.д.

 Отправлено: 07.10.06 06:59. Заголовок: Re:

цитата:

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

 Отправлено: 07.10.06 15:23. Заголовок: Re:

Кто-нибудь может привести толковый перевод вышенаписанного?

 Отправлено: 08.10.06 10:11. Заголовок: Re:

Ошибка синхронизации означает, что место, где должен быть заголовок фрейма (прямо после окончания предыдущего фрейма) не находится декодером.
[Прим: я так понимаю, просто "битый" заголовок фрейма]

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

После того, как выясняется, что заголовок фрейма поврежден, декодер ищет следующий набор битов, похожий на заголовок. В дейстивительности требуется 3 исправных заголовка и фрейма подряд, чтобы быть уверенным в том, что синхронизация восстановлена.

Во время загрузки файлов из сети могут случиться ошибки передачи, таким образом идея архивировать MP3 для выкладывания в сеть весьма неплоха, даже если это не дает выигрыша в размере. Ошибки быдут выявлены во время распаковки архива. Прерванные и возобновленные закачки также итогда порождают ошибки, по крайней мере я замечал это несколько лет назад. Похоже, сейчас алгоритмы возобновления закачек более совершенны.

 Отправлено: 08.10.06 13:19. Заголовок: Re:

Спасибо. Вот так просто и понятно всё разъяснено.

 Отправлено: 09.10.06 09:14. Заголовок: Re:

кстати у меня обнаружились ошибки в некоторых файлах, скачанных с cdonpc.ru с помощью их клиента.