Надо грабить в рабочее время На самом деле вопрос ведь в надежности - брастом тоже рипы в 75% случаев ничего получаются

я проверил и вот результаты (у меня дома 6 приводов и только один не кэширует аудио данные, и тот в ноутбуке, это к статистике):
привод PHILIPS DVD +-RW SDVD8441
track 60:51:05
результат без галки
0:10:00
6x
результат с галкой
0:14:01
4.3x

мне, честно говоря, просто смешно. было бы из-за чего поднимать такой шум. до тех пор пока EAC сам, жестко, не научится выставлять настройки привода, нельзя отключать галку для массового использования. это автоматически влечет кучу кривых рипов, и резко затрудняет определение корректности. для себя лично - запросто, только есть ли смысл. 4 минуты на диске - это гигантское приобретение в однозадачной системе. ну и для тех, кому надо сотню дисков в день рипнуть.

EDIT. проверял EAC, Range quality 99.9 %

This post has been edited by ShirA on 01-03-2007, 11:55

прочитал я ваше обсуждение на том сайте. мужик, хоть и хамит постоянно, но по сути во многом прав. однако:
1. пусть он свой эксперимент с нерой сделает на диске, который EAC не однократно перечитывает, тады и посмотрим.
2. общий смысл его утверждений можно представить примерно так " я на своем бамбуке вписываюсь в поворот на 90км\ч, какой идиот поставил знак 50?" у такого человека наверняка много друзей.
3. очень хотелось бы посмотреть, как он, на вызывающих доверие форумах, со своим даром убеждения, доказыват свою правоту (о чем писал Сергей Иванович)

This post has been edited by ShirA on 01-03-2007, 02:37

Ну как я прочитал в ЕАЦ при удержании мыши на етой опции пишется, что буфер он сбрасывает путем его забивания другими данными, т.е. читая столько же впустую сколько и по делу. Или я гоню?

нет, т.к. диска, даже слегка поцарапанного не нашел у себя дома Для чистоты експеримента хочется попробовать как на нулевом диске, так и на уже заслушанном до царапин Сегодня у кого-нибуть возььму поцарапанный и буду привод мучить

ето в чем проверялось? Если в ЕАЦ, то как сказал Фил

Если нет, то что говорит ЕАЦ?

Для меня лично есть смысл, я ведь не предлагаю мануалы переписывать (в отличие от того Кукса ), мне теперь уже самому интересно стало, а нафига я трачу столько времени, если качество рипа при етом не меняестя ни на грамм, привод у меня все равно аудио не кеширует...

похоже, что ты прав. иначе откуда разница. хотя, в таком случае, она должна быть около 2 раз или нет?

не понял, это ты о чем?

сомневаюсь, сейчас проверю. проверил на PIONEER DVD-RW DVR-111D. явно не отключает, разница слишком большая (43:07.81;0:06:12,6.9x;0:03:55,10.9x)

вот тут я не догоняю, что ты дальше будешь делать с таким рипом. или ты для себя бэкапишь?

This post has been edited by ShirA on 01-03-2007, 12:51

Ты чем проверял способность твоего привода кешировать аудио данные? Если в ЕАЦ, то при данном результате он сам отключит данную настройку, ставишь ты галочку или нет.

Около половины дисков граблю для себя. Т.к. я их отдаю обратно. Да и в чем проблема залить подобный релиз на нетлаб? Кеширование аудиоданных ведь мой привод не поддерживает, точнее наоборот, он поддерживает некеширование аудиоданных

This post has been edited by timtima on 01-03-2007, 13:16

если бы он так делал, откуда бы возникла наша дискуссия?

ну, если тебе не в облом это каждый раз доказывать, то тогда - конечно.

Все оттуда же

Давайте пофлудим, разобрав все варианты данной настройки:

1. ЕАЦ определяет, что привод кеширует аудиоданные, и привод на самом деле ето делает. В данном случае, как сказал Фил, пофигу отмечаем мы галочку или нет, т.к. ЕАЦ и так понял, что рип нужно снимать точный, значит будет забивать кеш, тем самым очищая его. Рип получится у нас точный, независимо от того отмечена галочка или нет в данной настройке. Если Фил не прав, и ЕАЦ не очищает кеш, то галочку нужно ставить (но мне кажется, что включением данной галочки мы просто заставляем ЕАЦ очищать кеш, не рассчитывая на него, да и Фил ведь не зря мозг клуба )

2. ЕАЦ определяет, что привод кеширует аудиоданные, но привод на самом деле етого не делает. Не велика беда, если привод етого не делает, то рип получится 100% точным, независимо от того, что думает ЕАЦ и включаем ли мы ету опцию.

3. ЕАЦ определяет, что привод не кеширует аудиоданные, и привод на самом деле етого не делает. Тот же самый вариант, раз привод данных не кеширует, то и рип получится правильный.

4. ЕАЦ определяет, что привод не кеширует аудиоданнные, но привод ето делает. Самый геморойный вариант Именно в таких случаях нам нужно или ставить галочку по любому, чтобы избежать ошибок с кешом.

Выводы:
а) если ЕАЦ определил, что привод кеширует данные, то хоть ставь галку, хоть не ставь, результат будет точным, економии времени не будет, но и рип будет достоверным.
б) если ЕАЦ определил, что привод не кеширует данные, то нам нужно удостовериться в етом, протестив сидюк в Феурио. При подтверждении тестом решения ЕАЦ о некешировании аудиоданных спокойно отключаем ету опцию, тем самим економя 4-5 минут на рипе каждого диска. При несхождении результатов тестов ЕАЦ и Феурио, ставим галку, тем самым принуждая ЕАЦ считывать инфу впустую для качественного рипа.

Ну релизы я делаю в основном только на два трекера (изредка на три), так что в оформлении останется только давать ссылку на данную тему

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

ну ето тоже не ясно Может если ЕАЦ определяет, что привод кеширует данные, то он вообще не обращается к кешу, на етом и економится время.

ето ты в Feurio проверил? Потому что ЕАЦ может по етому поводу гнать.

This post has been edited by timtima on 01-03-2007, 15:39

блин речь о том и идет. ссылка на эту тему ничего не дает. кто знает. правильно ли ты определил свойства своего привода, которые могут измениться с другой прошивкой. ты готов составить мировую базу данных? никто не отрицает, что возможен корректный рип с не отключенным кэшем. но в ЧАСТНОМ случае. как стандарт, на данный момент, это абсолютно не приемлемо. т.к. нет документального подверждения свойств конкретного привода с конкретной прошивкой, то для единиц, знающих эти свойства - экономия времени (не в разы!), а для большинства пользователей - элементарная провокация и путаница.

еще раз: я готов согласиться с корректностью рипа, если релизер, не отключая кэш, будет КАЖДЫЙ РАЗ приводить результаты тестирования своего привода на работу с кэшем. может ты его перешил и считаешь, что ничего не изменилось, а он уже кэширует аудио данные. тебе это надо? делаешь-то ты рип для ДРУГИХ людей. согласись, они имеют право знать, что именно им предложено.

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

сейчас, для чистоты эксперимента проверю, ежели feurio найду.

EDITED
нашел:

Manufacturer: PIONEER, Product: DVD-RW DVR-111D, Version: 1.23
Cache size: 2000 kByte
++ Cache test
+++++++++++++++++++++++++

Feurio! will now try to determine the size of the cache memory usable for audio data and the max. transfer rate.
To do so, Feurio! will read a certain number of sectors repeatedly and measure the transfer rate.

First 1 sector will be read repeatedly, then 2 sectors, and so on.
Normally the transfer rate will increase, because the more sectors are read, the fewer search operations will be needed.

Number of sectors: 1 (=2 kByte) -> 1.070 MBytes / second
Number of sectors: 2 (=4 kByte) -> 2.126 MBytes / second
Number of sectors: 3 (=7 kByte) -> 2.926 MBytes / second
Number of sectors: 4 (=9 kByte) -> 3.810 MBytes / second
Number of sectors: 5 (=11 kByte) -> 4.583 MBytes / second
Number of sectors: 6 (=14 kByte) -> 5.791 MBytes / second
Number of sectors: 7 (=16 kByte) -> 6.502 MBytes / second
Number of sectors: 8 (=18 kByte) -> 6.891 MBytes / second
Number of sectors: 9 (=21 kByte) -> 7.895 MBytes / second
Number of sectors: 10 (=23 kByte) -> 7.961 MBytes / second
Number of sectors: 15 (=35 kByte) -> 4.965 MBytes / second
Number of sectors: 22 (=51 kByte) -> 7.904 MBytes / second
Number of sectors: 33 (=77 kByte) -> 6.303 MBytes / second
Number of sectors: 49 (=115 kByte) -> 5.539 MBytes / second
Number of sectors: 33 (=77 kByte) -> 5.132 MBytes / second
Number of sectors: 49 (=115 kByte) -> 5.084 MBytes / second
Number of sectors: 73 (=171 kByte) -> 6.019 MBytes / second
Number of sectors: 109 (=256 kByte) -> 3.140 MBytes / second
Number of sectors: 163 (=383 kByte) -> 1.982 MBytes / second
Number of sectors: 244 (=573 kByte) -> 2.234 MBytes / second
Number of sectors: 366 (=860 kByte) -> 2.358 MBytes / second
Number of sectors: 549 (=1291 kByte) -> 2.542 MBytes / second
Number of sectors: 823 (=1935 kByte) -> 2.617 MBytes / second
Number of sectors: 1234 (=2902 kByte) -> 2.752 MBytes / second
Number of sectors: 1851 (=4353 kByte) -> 2.777 MBytes / second
Number of sectors: 2776 (=6529 kByte) -> 2.862 MBytes / second
Number of sectors: 4164 (=9793 kByte) -> 2.888 MBytes / second
Number of sectors: 6246 (=14690 kByte) -> 2.938 MBytes / second
Number of sectors: 9369 (=22035 kByte) -> 2.963 MBytes / second
Number of sectors: 14053 (=33052 kByte) -> 3.026 MBytes / second
Number of sectors: 21079 (=49577 kByte) -> 3.089 MBytes / second

-------------------------------
Result:
Maximum transfer rate: 7961 kBytes/Second
Cache size for audio data: 51 kByte

############################################
#### FINISHED
############################################

This post has been edited by ShirA on 01-03-2007, 19:00

Эээ... судя по нашим выводам, если EAC решил, что привод кеширует данные, то галка не должна влиять на скорость.
Как-то оно всё странно.

Я даже не заикался о предложении менять мануалы LF_ и Overkilla, тем более не думал предлагать менять стандарты. Я веду данную дискуссию исключительно в егоистичных целях- економии личного времени.

А почему бы и да? Баз офсетов завались, которые по моему мнению влияют на процесс грабления куда меньше, как в смысле точности, так и затрачиваемого времени. Так почему бы не составить базу хотя бы тех приводов, которые заведомо не кешируют аудио данные, тем самым дав возможность многим людям секономить время и породить хаос в "идустрии" передачи лосслесс имиджей?

спасибо за участие

Ага, получается, что или он все же рипает с повторной проверкой из кеша, или он вообще перестает обращаться к нему, заведомо предполагая наличие в нем ошибок. В первом варианте придется ставить галку, во втором нет. Но путаницы можно избежать наличием обязательной галки в том случае если ЕАЦ или Феурио обнаруживает кеширование аудио данных (как сейчас и есть в стандарте). Картинка так же вроде складывается, что кеширование аудио данных зависит в большинстве своем от производителя приводов: Lite-on все кешируют (правда протестины пока только 2 =) ); Неки наоборот, ни один не кеширует. Я наверно на досуге займусь созданием такой базы, если желание не пропадет и времени свободного хватит (того самого, которое может быть секономлю на рипах без етой галки)

намерение, которое не может не вызывать уважение