Close Topic Options

Артист: Various Альбом: Various, Жанр: Хоровые пения Формат файла: EAC/CUE/APE Ссылка: CD Нахождение: Torrent Примечание: Релиз содержит сканы

1. Various - Ave Maria in cursu Milleniorum
2. Capella Antiqua Munich - Te Deum Laudamus - Gregorian Chants
3. Choir of the Russian Ecclesiastical mission in Jerusalem
4. Chior of the Russian Orthodox Cathedral, Paris - Russian Liturgical Chant
5. Choral Acadamy of Moscow - Russian Sacred Concert
6. Ensemble vocal Kedroff - Chants liturgies russes - voix d'hommes

Пример лога

CODE

EAC extraction logfile from 24. September 2005, 22:39 for CD Various / Ave Maria in cursu Milleniorum Used drive  : HL-DT-STDVDRAM GSA-4081B   Adapter: 1  ID: 1 Read mode   : Secure with NO C2, accurate stream, NO disable cache Read offset correction : 667 Overread into Lead-In and Lead-Out : No Used output format : Internal WAV Routines                      44.100 Hz; 16 Bit; Stereo Other options      :     Fill up missing offset samples with silence : Yes     Delete leading and trailing silent blocks : No     Installed external ASPI interface Range status and errors Selected range      Filename G:\Music\Ave Maria in cursu Milleniorum\Various - Ave Maria in cursu Milleniorum.wav      Peak level 89.1 %      Range quality 99.9 %      CRC 3049F9AD      Copy OK No errors occured End of status report

Объем релиза: 1 551 278 604
Скорость аплоуда: до 16 кб/с (да, а шо делать....)

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

This post has been edited by deadhead_ on 25-02-2007, 21:36

Объем релиза: 1 551 278 604
Скорость аплоуда: до 16 кб/с (да, а шо делать....)

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

Post Link: Как пользоваться Шаблоном

deadhead_!!! Большое спасибо за релиз!!!

Zemlynin

Я вижу шаблон, но криво получается, так как это тематический сборник - диски разных издателей по теме

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

This post has been edited by ShirA on 25-02-2007, 03:53

Ты оформи,а я потом подправлю если что
Спасибо!

ShirA
Без паники Диски уже недоступны.
И галка эта на практике не должна была повлиять на качество граба

на чем основывается такое смелое утверждение? буфер у привода есть - есть, проблемы со считыванием адио есть - есть. вот данные ixbt по этому приводу:

LG GSA-4081B
Спецификация
* Интерфейс: E-IDE/ATAPI
* Скорость чтения:
o CD-ROM/R: 32x Max.
o CD-RW: 24x Max.
o DVD-ROM: 12x Max.
o DVD-R/RW: 8x Max.
o DVD+R/+RW: 8x Max.
o DVD-RAM: 3x, 2x, 1x
* Скорости записи:
o CD-RW: 16x, 10x, 8x, 4x
o CD-R: 24x, 16x, 8x, 4x
o DVD-RW: 2x, 1x
o DVD-R: 4x, 2x
o DVD+RW:4x, 2.4x
o DVD+R: 8x, 4x, 2.4x
o DVD-RAM: 3x, 2x
* Поддерживаемые форматы:
o DVD: DVD-ROM, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD-RAM
o CD: CD-ROM, CD-ROM XA, CD-DA, CD-Extra, CD-Text, CD-R (Orange Book Part 2), and CD-RW (Orange Book Part 3), Supports High Speed Disc Media, Reads Photo CD (Single and Multi-Session), Reads CD-I and Video CD
* Время доступа
o CD-ROM: 135ms (Typical)
o DVD-ROM: 155ms (Typical)
o DVD-RAM: 185ms (Typical)
* Размер буфера данных: 2MBytes
* MTBF 100,000 POH
* Размеры: 146mm x 180mm x 41.3mm
* Вес 0,94 kg
...В частности, точность извлечения аудио треков приводом стоит под большим вопросом, так как некоторые тесты выявили большое число ошибок возникающих во время этой операции.

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

ShirA
Нет желания - не бери, для этого и выложен пример ЛОГа.

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

deadhead_

скажи а что сложно сделать по нормальному стандарту :? всё что нужно сделать поправить одну опцию

Topic Link: Создание музыкальных релизов.

ты зря обижаешься. никто не пытется на тебя "наехать". здесь вообще такое не принято.
очень рекомендую, кроме приведенной выше ссылки почитать и работу от LF_, там очень понятно и подробно описано что, как и почему.

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

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

успехов

P.S. т.к. логи у тебя не правильные, имело смысл привести их от всех дисков. возможно, были рипы у которых "Range quality" = 100%, такие диски могли бы скачать те, кто не качает не стандартные рипы. музыка-то великолепная.

Большое спасибо за релиз! Клас! Может быть ещё что-то в етом духе имеется?

ты зря обижаешься. никто не пытется на тебя "наехать". здесь вообще такое не принято.
очень рекомендую, кроме приведенной выше ссылки почитать и работу от LF_, там очень понятно и подробно описано что, как и почему.

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

Веду дискуссию на другом сайте по поводу полезности включения данной опции. Выдали мне вот такую вот фразу:

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

This post has been edited by timtima on 28-02-2007, 17:09

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

да, любят, так называемые, спецы поливать тех, кто еще не до конца разобрался.
задай этому крупному специалисту простой вопрос: "Чем может помешать галка, отключающая кэш (а она именно отключает его) приводу, который и так его не использует, при аудио рипе?"
получается, что и так, и так - кэш не используется, но присутствие галки отмечено в логе EAC, а о том, что привод с какой-то конкретной прошивкой не кэширует аудио данные, знает только несколько "крутых" спецов. по этому и существует НетЛабовский стандарт. по нему не надо выяснять какая прошивка стоит на конкретном приводе, он, и это много раз проверено, обеспечивает корректный рип (с доказательством в логе) для любого.

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

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

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

This post has been edited by ShirA on 28-02-2007, 18:36

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

да, любят, так называемые, спецы поливать тех, кто еще не до конца разобрался.
задай этому крупному специалисту простой вопрос: "Чем может помешать галка, отключающая кэш (а она именно отключает его) приводу, который и так его не использует, при аудио рипе?"
получается, что и так, и так - кэш не используется, но присутствие галки отмечено в логе EAC, а о том, что привод с какой-то конкретной прошивкой не кэширует аудио данные, знает только несколько "крутых" спецов. по этому и существует НетЛабовский стандарт. по нему не надо выяснять какая прошивка стоит на конкретном приводе, он, и это много раз проверено, обеспечивает корректный рип (с доказательством в логе) для любого.

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

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

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

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