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

Заодно попробуй тестировать на другой скорости - 4х например или 16х

2 Vodochnik:
Спасибо, заценил твою шутку о третьем процессоре для двухпроцессорной мамы. Предложил использовать мод-рирайт чтобы переход для всех был лёгким и незаметным. Если ресурсы не позволяют то на нет и суда нет.

Различные текстовые редакторы работающие на разных осях и в разных локалях могут обрабатывают нетекстовые символы и переводы строк по-своему:
- Нетекстовые по мнению редактора символы могут быть изменены на текстовые при чтении или записи файла;
- Символы возврата каретки и перевода строк и(ли) их комбинации могут быть преобразованы в стандартные для конкретной оси (CRLF для винды, LF для линуха, CR для мака);
- Файл может быть прочитан не до конца если текстовый редактор наткнулся на ноль или символ конца файла;
- могут быть добавлены лишние символы перевода строк - если по мнению редактора строка очень длинная;

В частности, виндусовый notepad уличён в замене нулевых байтов на пробелы.



Собственно Мы говорили о всём торрент-файле, не только о первой сотне байтов - да, Мы согласны - в первой сотне байтов нет нулей и прочих CRLF. Первая сотня байтов сохранится правильно даже из-под текстового редактора. Мы беспокоились о другой части торрент-файла - там где md5-суммы кусков в двоичном виде...


Почему не сделать пару-тройку простых тестов? - открыть торрент файл в текстовом редакторе (например notepad или write под виндовсом или vim под никсом), сохранить его без изменений под другим именем и побайтно сравнить* результат с оригиналом.

______________________________________________
[*] пример консольной команды для сравнения нетекстовых файлов под виндой:
fc /b filename.torrent filenameSavedAs.torrent
или посчитать и сравнить контрольные суммы файлов.

1. При записи каждый текстовый редактор толкует CR и LF по-своему и до первого нуля или ^Z. Надо брать шестнадцатеричный, к примеру какой-нибудь XVI32 если под win32.
2. d8:announce79:http://tracker.rusdivx.net/.....



1. мод рерайт уже используется на докувике, не так ли?
2. до сих пор простаивает пустой слот?!!???

2 Bubble-Gum:


Что если примерно такой .htaccess положить в диру старого треккера? Тогда 20000+ пользователям не надо срочно заморачиваться с заменой анонс-урла в каждом торренте... К слову, пункт (а) из первого поста содержит 2 неточности - такой .torrent файл работать не будет.
Ну, и... scrape задалбывает не хуже анонса, так его тоже отключать, да?

VideoHelp не поможет?

нифигасе, уже 21 модель с поддержкой mpeg4-hd ..

Мистика какая-то

Она в little endian. Это уже хорошо . Попробуй прогнать её через ac3fix. Хотя...это врядли поможет. Я посмотрю завтра, у меня была прога типа ac3fix, но с проверкой контрольных сумм пакетов. Смотреть?

Посмотри hex-вьювером внутрь выдранного AC3 файла и найди первые 2 байта 0B 77 или 77 0B - в каком они порядке? Возможно, AC3 дорога в big endian (рипалось на маке?).

Счётчик имеет мало смысла, потому что:
- Скачан 5548 раз и
- 5548 раз послан event=completed
это 2 большие разницы (тонкий намёк на e2k plugin)



При этом к-во просмотров страницы 3236 Ж)

пара небольших дополнений:
- Они отказались от встроенных текстовых субтитров в пользу встроенных битмаповых из-за проблем с кодировками и спец. символами.
- Несколько аудио дорог они позиционируют как фичу в DMF. Наверное, маркетинговый ход...

Спасибо за обсуждение, оффтоп можно удалить, соглашение достигнуто.

Мне показалось, в цитате речь шла именно о технической (не)возможности проиграть материал с DMF на большинстве плееров, как и в случае материала в mkv или ogm. Извините если понял неправильно.

Понятие 'extension to AVI' в отношении к DMF активно использовалось на форумах дивикса, гидрогена и дума 1.5 года назад. Какое понятие используют сегодня - не в курсе.

Такая фича DMF как 2 аудио дороги имеется например здесь и здесь. (реализация этой фичи в DMF идентична open dml)

Список INFO c чанком ISFT присутствует почти во всех avi файлах из 1, 2, 3, 4.
Также, широкий выбор инфо-чанков есть во многих файлах из этой категории.
Иногда попадается чанк strn из strl списка (нет ссылки на конкретный материал) - результат от AVIMux-GUI.
Эти чанки не поддерживаются большинством плееров.
AVIX чанк есть тут, тут и тут. Он не поддерживается некоторыми плеерами, например dvp642 - невозможно посмотреть окончание фильма.
(дисклаймер: под поддержкой чанка я понимаю его распознавание, чтение-интерпретация содержимого, и выполнение действия. Ожидаемое действие для чанков из инфо - это вывод информации. Таких плееров не попадалось..)

Плеер должен прыгать через чанки которые не 'понимает'.

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

Кодировка XSUB - это 4х-битный png (поправьте если ошибаюсь) - как и на DVD - декодер грузит мало и редко.

Проблемы с интерливом начинаются там, где заканчивается буфер , характерны для плееров с минимальными 512KB памяти, на материале с высоким битрейтом и b-фреймами.

2 starsoft:
Вы во второй раз используете разные понятия в одном смысловом контексте: контейнер и расширение контейнера.

Вы хотите сказать, что при аккуратном добавлении нескольких левых чанков внутрь AVI структуры, плеер не будет играть этот AVI-файл? позволю усомнится.
Или вы думаете, что расширение DMF выворачивает всю AVI-структуру наизнанок?

Поскольку mkv неоднократно упоминался, можно линк на полный список плееров с поддержкой матрёшки в студию? и заодно кто сертифицирует поддержку? (я как-то упустил этот момент из вида, каюсь)


Тем не менее несмотря ни на что и вопреки всему, на форуме-треккере давно и успешно раздаётся как материал с элементами DMF, так и материал с неизвестными для плеера чанками. Несовместимости замечено не было.

Есть 2 реальные причины, почему DMF не рекомендуется:
- отсутствие нормальных тулзов для операций над контейнером и авторинга DMF фичей.
- XSUB. Спецификация AVI позволяет иметь более одного видео-потока. К сожалению, многий софт, начиная с M$ DirectShow AVI Splitter и заканчивая VirtualDubMod, воспринимает только один видео-поток. Это недоработка конкретного софта, а не спецификаций AVI или DMF, но она серьёзно препятствует использованию DMF c XSUB на компе. К плееру это не относится.

1. DivX Media Format - это НЕ новый контейнер. Это добрый старый AVI.
2. Плееров умеющих играть DMF со всеми прибамбасами уже как грязи (ключевое слово Ultra-certified) и будет ещё больше.
3. Остальные плееры (не Ultra-certified) обязаны переварить DMF и проиграть Main Title. Лично пробовал навороченный DMF на 2-х древних плеерах (dvp642 lda531) - Main Title играли без проблем!

резюме - DMF РЕКОМЕНДУЕТСЯ!

Ни то, ни другое ни третье

На RDA, как и на многих других частных треккерах, введены эффективные меры против DHT/PEX/TT:

Это во-первых, принудительная модификация .torrent-файла при заливке на треккер - устанавливатся private флаг в infohash директорию.
И во-вторых, на треке разрешено использование только таких клиентов, которые отключают DHT/PEX/TT на частном торренте, или не имеют этих фич.

То есть, юзер может включать DHT, если не жалко трафа. Правильный клиент не выпустит частный торрент в DHT. Но есть один ньюанс.
Приведу пример: Разработчик декларировал правильную работу BC060 на частном треке. Но в программе был баг - при определённых условиях пасскей раздавался всем желающим.
Администрация не в состоянии тестировать каждый клиент на соответствие правилам игры, потому рекомендует отключать DHT/PEX/TT в клиенте т.к. хочет обезопасть пользователя от кражи пасскея.

Если юзер включил DHT/PEX/TT, про#$%ал свой паскей, из под его account выкачали терабайт, юзер пошел мыться, кто будет виноват?

Внесу небольшую поправку. DHT не участвует в распространении пасскея. Это делает фича известная как Trakerless tracking.

Вопрос был задан на форуме с частным треккером, не так ли? Ответ по теме:
DHT надо отключать по 3-м причинам:
- оно отжирает драгоценного траффика;
- оно создаёт дополнительную нагрузку на ресурсы компа;
- ну и каго ви сабираитись наити в DHT?

Найди подругу (или друга) с пишущим DVD приводом от LiteOn или BenQ, захвати нормальный диск для сравнения и проверь диски на PIE/POF (kprobe или nero cd/dvd speed-ом соответственно) - cам всё поймёшь...


ЗЫ. ВСЕ минусовые диски к-рые попадали в руки, имели уровень ошибок, на ПОРЯДКИ выше, чем плюсовые. выбор очевиден...

Без разницы каким софтом записывать - на качество записи это не влияет. PgcEdit+ImgBurn(ака Decryptor) более предпочтителен, т.к. позволяет руками выставить layer break в 'самое правильное' место. (Nero ставит layer break между первыми попавшимися cells.)

MKM 001(Verbatum) - рулит однозначно.
RITEK D01(Memorex) - отстой, 50% уходит на подставки под пиво.

На качество записи влияет болванка, скорость записи, привод и его firmware.

После прожига проверяю диски не в плеере, а на предмет ошибок собственно носителя (PIE/PIF/POF). Диск с меньшим уровнем ошибок имеет больше шансов на безглючный playback.

Пишу только на +, проверяю носитель на ошибки, диски играют нормально, проблем не имею (проблемы имеет магазин куда сдаю взад стаканы с погаными болванками )

1. UDF. Не бывает DVD-Video без UDF по определению.

2. Болванки. По моему опыту с MKM 001 (=Verbatum, =Dynex) и BenQ 1640 BSMB, их надо писать на только на 4x. Качество выходит замечательное: PI(avg)=7.20, PIF(avg)=0.43, POF=0, Quality=92. НО - при попытке писать на 2.4x (скорость на упаковке) мой драйв их выблёвывает. Также присутствует опция 8х, но я боюсь

3. Nero. Все DL пишу Nero'й икспресс (6.6.0.18 OEM), на железе и компе проблем нет, даже переход слоя без запинки.

4. Буктайп - DVD-ROM, естественно. А что, при записи кто-то ставит другой?


seth, попробуй перехешировать скачанное, может криво скачалось.
Не помешает проверить записанную болванку на PIF-POF.

4.3 GB? на FAT ??

ты б посоветовал купить усилитель 1 квт RMS

2 andmarat:
avimp3gain тебе в помощъ

Делали те, у кого железный плеер с офигенным буфером, кеширующим полфильма , или те, у кого железного плеера вообще нету.

Для нас, владельцев ширпотреба с 4Мбит памяти и лейбом DivX Certified надо ставить 500ms прелоада интерлив 1 фрейм, mp3 и ac3. Encoding Audio for DivX® Certified Devices



Битрейт очень даже нехилый : DivX® Certified Technical Specifications
За твой плеер не скажу, но в своё время экспериментировал с разными прелоадами для плеера с ESS Vibratto II, материал ac3 448kbps, DivX ~1400kbps. Удовлетворительный результат был получен именно с 500ms / 1 frame. Прелоад 450ms и меньше приводил к затыканиям и сбою A/V синхронизации.

Попробуй сам - отрежь 3 минуты кина и сделай несколько клипов с разным прелоадом. И огласи результат