|
|
|
Songs0fFailure
Стаж: 16 лет 4 месяца Сообщений: 2896
|
Songs0fFailure ·
26-Янв-12 21:00
(13 лет 7 месяцев назад)
Цитата:
он допустил к её использованию ЕАС как риппер заносящий туда информацию.
а каким рипером тогда наполнять базу ? 0_o
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
26-Янв-12 21:34
(спустя 34 мин., ред. 26-Янв-12 21:34)
Songs0fFailure писал(а):
а каким рипером тогда наполнять базу
А, что у создателя AR нет своего, есть, но бесплатным для пользователя и до поры до времени таким его и оставлять. А желание "на ёлку влезть и задницу не ободрать", и "получить сразу и всё", не приводит ни к чему хорошему. Я уже говорил gchudov года, эдак, два назад, в этой-же теме только "старого разлива", то, что сказал в в этом посту и оборачиваясь назад, считаю что был прав, и это время потеряно в плане продвижения и риппера и базы.
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
26-Янв-12 21:47
(спустя 12 мин., ред. 26-Янв-12 21:47)
Cornerstone писал(а):
Да, база стала быстро пополняться, но и быстро становиться помойкой.
Это не совсем верно. Если бы был способ сделать ультранадёжный риппер, который никогда не ошибается, то никакие базы были бы не нужны. Но этого сделать нельзя.
Зато можно сделать базу. А её эффективность в определении хороших и плохих рипов прямо пропорциональна скорости пополнения. Не важно, сколько ошибочных контрольных сумм в неё заносится. Важно, сколько дисков имеют два и более независимых подтверждения одной и той же контрольной суммы.
Так что чем быстрее база пополняется, тем она меньше является помойкой. Качество риппера в таком случае непринципиально.
Cornerstone писал(а):
и эти два года потерянны в плане продвижения и риппера и базы.
Я бы так не сказал. Я считаю, что поддержка базы EACом - огромная победа в плане продвижения и риппера и базы. База стала пополняться в 10 раз быстрее, плюс солидный процент пользователей EAC, увидев в логе EAC сообщение о том что их рип может быть исправлен с помощью CUETools, идёт качать CUETools, и пробует CUERipper.
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
26-Янв-12 21:58
(спустя 11 мин., ред. 26-Янв-12 21:58)
gchudov
gchudov писал(а):
За несколько месяцев EAC пополнил базу в десятки раз больше, чем CUERipper за два года
по тому, что CUERipper проигрывает ЕАС, как минимум, в функционале, а раз проигрывает, и сильно, то и пользуются им меньше пользователей - всё закономерно, а если сам его автор считает
gchudov писал(а):
Качество риппера в таком случае непринципиально
именно так как написано выше, то и иначе чем сейчас складывается ситуация и не может. Надо идти, как говориться "от печки" - первостепенное значение имеет именно риппер, а не база или какая либо прога которая исправляет уже готовый рип, так как он первый "соприкасается" с оригиналом которым является CDDA.
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
26-Янв-12 22:05
(спустя 7 мин.)
Cornerstone писал(а):
потому, что CUERipper проигрывает ЕАС, как минимум, в функционале
Если функционалом считать 10000 настроек и бессмысленное замедление процесса копирования, то да. Но я ставил своей задачей немного другой функционал.
Cornerstone писал(а):
то и пользуются им меньше пользователей
Если бы большинство всегда пользовалось софтом, который лучше, то мир был бы устроен по другому  На стороне EACа прежде всего проверенность временем и закреплённость в правилах многих трекеров, например этого. Если использование CUERipper будет так же поощряться на трекерах, как использование EAC - картина будет совсем другая.
Cornerstone писал(а):
всё закономерно, а если сам его автор считает
gchudov писал(а):
Качество риппера в таком случае непринципиально
Эту цитату не стоит вырывать из контекста. Качество используемого риппера непринципиально для пополнения базы. Оно очень даже принципиально для пользователя риппера. Ну и для автора, конечно.
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
26-Янв-12 22:26
(спустя 21 мин., ред. 26-Янв-12 22:26)
gchudov писал(а):
Если использование CUERipper будет так же поощряться на трекерах, как использование EAC - картина будет совсем другая.
А, Вы назовите хоть одну причину по которой это должно происходить!
gchudov писал(а):
Эту цитату не стоит вырывать из контекста.
А, тут, вырывай, не вырывай, Вы ставите на первое место возможность быстрейшего пополнения базы, о чём и говорят все Вами предпринимаемые действия, но сами соглашаетесь с тем что это происходит за счёт стороннего риппера, и в то-же время ничего не делаете для того что-бы её пополнение шло за счёт родного. Разговор превращается в хождение по-кругу.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
27-Янв-12 13:21
(спустя 14 часов, ред. 27-Янв-12 14:01)
вот такой отчет:
bad boys blue - house of silence.flac.cue: CRC 4FFB2EF3, AR: rip not accurate (0/3), CTDB: verified OK, confidence 1
скрытый текст
[CUETools log; Date: 19.01.2012 20:00:02; Version: 2.1.2a]
Pregap length 00:00:33.
[CTDB TOCID: LmCXEp1n6hwkJ2JADV7cV8DXDJU-] found.
[ CTDBID ] Status
[192377a3] (1/1) Accurately ripped
[AccurateRip ID: 00039748-000df4b1-23047b04] found.
Track [ CRC ] Status
01 [aaa33f90] (0/3) No match but offset
02 [22c330a8] (4/4) Accurately ripped
03 [fe6c322c] (4/4) Accurately ripped
04 [e66a79bb] (4/4) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 99,9 [1E03BCF9] [750AC909] W/O NULL
01 99,9 [F357EE6B] [CBD12D71]
02 99,9 [269E4B84] [4D5E6C3F]
03 94,2 [5C64C907] [D3D2FEEA]
04 99,9 [7F12188D] [B5FDE673]
Получается, что CTDB этот рип добавлен через CUERipper и считается правильным, а по данным AR - выходит что рип имеет ошибку в первом треке.. так?
Далее. 2 прессинга одного и того же альбома.
sandra - mirrors.cue: CRC 3F995D8F, AR: rip accurate (17/17), CTDB: verified OK, confidence 11
скрытый текст
[CUETools log; Date: 27.01.2012 8:28:24; Version: 2.1.2a]
Pregap length 00:00:32.
[CTDB TOCID: eR1s.IMV3gpiNmWu_JnyIMua_.U-] found.
[ CTDBID ] Status
[832cf487] (11/11) Accurately ripped
[AccurateRip ID: 000b142c-00542595-78083a09] found.
Track [ CRC ] Status
01 [20c3ae64] (11/17) Accurately ripped
02 [14068f69] (11/17) Accurately ripped
03 [c97b9bd1] (11/17) Accurately ripped
04 [ae0c2cd1] (11/17) Accurately ripped
05 [52b6cf53] (11/17) Accurately ripped
06 [72818ba8] (11/17) Accurately ripped
07 [69b7f244] (11/17) Accurately ripped
08 [49395b2c] (11/17) Accurately ripped
09 [a5970877] (11/17) Accurately ripped
Offsetted by -1328:
01 [e37cae57] (03/17) Accurately ripped
02 [2a967b3f] (03/17) Accurately ripped
03 [efd2ad27] (03/17) Accurately ripped
04 [27404d2f] (03/17) Accurately ripped
05 [8a6693a9] (03/17) Accurately ripped
06 [cc0725e3] (03/17) Accurately ripped
07 [39d0da35] (03/17) Accurately ripped
08 [3ef0f392] (03/17) Accurately ripped
09 [fa88c68c] (03/17) Accurately ripped
Offsetted by -664:
01 [7f1d3fd1] (03/17) Accurately ripped
02 [9365913d] (03/17) Accurately ripped
03 [bafff05d] (03/17) Accurately ripped
04 [614d253e] (03/17) Accurately ripped
05 [b66964f6] (03/17) Accurately ripped
06 [68659c13] (03/17) Accurately ripped
07 [87dc76e8] (03/17) Accurately ripped
08 [6c18ec19] (03/17) Accurately ripped
09 [afcb4874] (03/17) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [099450DF] [C2F52540] CRC32
01 34,5 [C4BDC51B] [E55F51A9]
02 98,1 [4226F2B5] [99B17BB7]
03 94,9 [9E683D29] [7BEA9182]
04 100,0 [5F4F6E1A] [CD169AFD]
05 100,0 [74EC2980] [A3E03C86]
06 100,0 [2FC27BB6] [8B0AC9F3]
07 94,6 [E511A103] [EA896547]
08 100,0 [95DC8CB8] [D62BA9C2]
09 96,6 [FBF623E9] [08EC8AA5]
mirrors [flac].cue: CRC 10017570, AR: offset 594, rip accurate (1/1), CTDB: could not be verified
скрытый текст
[CUETools log; Date: 27.01.2012 14:05:24; Version: 2.1.2a]
[CTDB TOCID: eR1s.IMV3gpiNmWu_JnyIMua_.U-] found.
[ CTDBID ] Status
[832cf487] (11/11) Has pregap length 00:00:32
[AccurateRip ID: 000b12ec-00541eb6-72083909] found.
Track [ CRC ] Status
01 [cdb402a0] (0/1) No match
02 [3a6cf52f] (0/1) No match
03 [36eae9c2] (0/1) No match
04 [780f1082] (0/1) No match
05 [136d8510] (0/1) No match
06 [5be0b312] (0/1) No match
07 [7c6d204d] (0/1) No match
08 [62f21055] (0/1) No match
09 [d56e947f] (0/1) No match
Offsetted by 594:
01 [20c3ae64] (1/1) Accurately ripped
02 [14068f69] (1/1) Accurately ripped
03 [c97b9bd1] (1/1) Accurately ripped
04 [ae0c2cd1] (1/1) Accurately ripped
05 [52b6cf53] (1/1) Accurately ripped
06 [72818ba8] (1/1) Accurately ripped
07 [69b7f244] (1/1) Accurately ripped
08 [49395b2c] (1/1) Accurately ripped
09 [a5970877] (1/1) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [A621EC35] [0F270D11]
01 34,5 [5342C8FE] [49092125] CRC32
02 98,1 [70477B91] [2392961D] CRC32
03 94,9 [16B1F89C] [9434C573] CRC32
04 100,0 [FEFA4504] [3E442B71] CRC32
05 100,0 [C299A886] [5BE81ECA] CRC32
06 100,0 [C4DAC327] [408A8BB5] CRC32
07 94,6 [C07DFA02] [30E0B28E] CRC32
08 100,0 [4CCE2F93] [FDF2D8DA] CRC32
09 96,6 [7BD396BB] [369BA745] CRC32
Что значит CTDB: could not be verified и с прегапами совсем запутанно - получается, что аудиочасть одна и таже, только в одном из вариантов альбома нет прегапа?
И еще, для второго альбома, вышеприведенный отчет можно получить только, если проверять этот альбом отдельно, а проверка в пакетном режиме дает следующий отчет:
скрытый текст
[CUETools log; Date: 27.01.2012 14:24:45; Version: 2.1.2a]
[CTDB TOCID: eR1s.IMV3gpiNmWu_JnyIMua_.U-] found.
[ CTDBID ] Status
[832cf487] (11/11) Has pregap length 00:00:32
[AccurateRip ID: 000b12ec-00541eb6-72083909] found.
Track [ CRC ] Status
01 [cdb402a0] (0/1) No match
02 [3a6cf52f] (0/1) No match
03 [36eae9c2] (0/1) No match
04 [780f1082] (0/1) No match
05 [136d8510] (0/1) No match
06 [5be0b312] (0/1) No match
07 [7c6d204d] (0/1) No match
08 [62f21055] (0/1) No match
09 [d56e947f] (0/1) No match
Offsetted by 594:
01 [20c3ae64] (1/1) Accurately ripped
02 [14068f69] (1/1) Accurately ripped
03 [c97b9bd1] (1/1) Accurately ripped
04 [ae0c2cd1] (1/1) Accurately ripped
05 [52b6cf53] (1/1) Accurately ripped
06 [72818ba8] (1/1) Accurately ripped
07 [69b7f244] (1/1) Accurately ripped
08 [49395b2c] (1/1) Accurately ripped
09 [a5970877] (1/1) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL]
-- 100,0 [A621EC35] [0F270D11]
01 34,5 [5342C8FE] [49092125]
02 98,1 [70477B91] [2392961D]
03 94,9 [16B1F89C] [9434C573]
04 100,0 [FEFA4504] [3E442B71]
05 100,0 [C299A886] [5BE81ECA]
06 100,0 [C4DAC327] [408A8BB5]
07 94,6 [C07DFA02] [30E0B28E]
08 100,0 [4CCE2F93] [FDF2D8DA]
09 96,6 [7BD396BB] [369BA745]
То есть, лог-файла в пакетном режиме, как я понимаю, программа не видит. (При одиночной проверке данного рипа программа выводит окно "select the best match", где показывается один единственный лежащий в папке лог-файл).
имена файлов
Mirrors [FLAC].CUE
Mirrors.log
Но, при этом, в соседней же папке - такая же петрушка с именами файлов
The Wheel Of Time [FLAC].CUE
The Wheel Of Time.log
И если этот рип проверять, в числе прочих, в пакетном режиме - то в итоговом отчете таки присутсвует колонка [LOG]! а при одиночной проверке данного рипа программа не выводит окно "select the best match".
Вобщем непонятна логика работы в данном случае. И еще непонятно - почему программа игнорирует лог файл, когда он единственный доступный в папке и предлагает выбрать лучший вариант при единственном доступном.
|
|
|
|
simple.i
Стаж: 16 лет 9 месяцев Сообщений: 8442
|
simple.i ·
27-Янв-12 13:37
(спустя 15 мин.)
omegalord писал(а):
Получается, что CTDB этот рип добавлен через CUERipper и считается правильным
Не считается правильным - просто добавлен через CR или EAC. Скорее всего, добавлен тем, кто этот рип делал. Оценить "правильность" рипа в CTDB можно только самому по количеству совпадений. Об этом уже писалось в теме.
omegalord писал(а):
Далее. 2 прессинга одного и того же альбома.
У этих прессингов DISKID разные. Они воспринимаются базами как разные диски.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
27-Янв-12 15:05
(спустя 1 час 27 мин., ред. 27-Янв-12 15:05)
simple.i писал(а):
omegalord писал(а):
Получается, что CTDB этот рип добавлен через CUERipper и считается правильным
Не считается правильным - просто добавлен через CR или EAC. Скорее всего, добавлен тем, кто этот рип делал. Оценить "правильность" рипа в CTDB можно только самому по количеству совпадений. Об этом уже писалось в теме.
"Считается" - всего лишь термин Имелось ввиду что две базы дают противоположные заключения по рипу. Меня это немного смутило, поэтому решил уточнить.
simple.i писал(а):
omegalord писал(а):
Далее. 2 прессинга одного и того же альбома.
У этих прессингов DISKID разные. Они воспринимаются базами как разные диски.
Да, диски разные, но почему для разных дисков показывается , в обоих случаях, [832cf487] (11/11) и почему для одного диска пишется Has pregap length 00:00:32 - в четвертой строке, а для другого - Pregap length 00:00:32. во второй строке?
И что значит надпись CTDB: could not be verified?
Еще, проблема.
Проверил папку с рипами в пакетном режиме. Один из рипов - "crc mismatch" из за чего вся толпа потенциалльных двойников (уже проверенных) тусит вместе с ним в подразделе "not yet verified".
Что еще хуже, что стоит только покинуть это окно, как, информация о том, что данный рип "crc mismatch" - исчезает, и показывается уже просто как "never verified"
На мой взгляд - тут сразу 2 существенных недостатка.
1. теряется важная информация о том, почему не удалось проверить рип ( в данном случае информация о том, что файл битый). придется отдельно проверять каждуй папку которая never verified - что бы понять в чем дело
2. уже проверенные рипы остаются в разделе - "not yet verified"
А вот еще более запутанный случай - после проверки папки в пакетном режиме получаем:
а.
а рипы все равно остаются в разделе "not yet verified".
Теперь, достаточно просто перейти в другой раздел и вернуться обратно чтобы получить следующий результат.
б.
Три отчета трансформировались в "never verified". Жмем кнопку "поехали" (с галочкой в чекбоксе "skip recently verified") - отчет без всяких проверок, в ту же секунду, возвраващется к виду "а". При этом все рипы, все так же остаются в подразделе "not yet verified".
|
|
|
|
simple.i
Стаж: 16 лет 9 месяцев Сообщений: 8442
|
simple.i ·
27-Янв-12 15:32
(спустя 26 мин., ред. 27-Янв-12 15:32)
omegalord писал(а):
Имелось ввиду что две базы дают противоположные заключения по рипу.
Откуда Вы взяли что базы дают какие-то заключения? Фраза Accurately ripped в данном случае (да и в остальных тоже) означает, что проверяемый рип совпадает с экземпляром, имеющимся в базе, не более. Заключение о правильности рипа базы не делают, его Вы делаете сами, на основании полученной от баз информации.
omegalord писал(а):
Да, диски разные, но почему для разных дисков показывается , в обоих случаях,[832cf487] (11/11) и почему для одного диска пишется Has pregap length 00:00:32 - в четвертой строке, а для другого - Pregap length 00:00:32. во второй строке?
В одном рипе есть предзазор, а в другом нет - отсюда и разница. Программа дает информацию о том, что данный диск имеет предзазор такого-то размера.
omegalord писал(а):
И что значит надпись CTDB: could not be verified?
Не может быть проверен средствами программы. Типа "не шмогла". 
omegalord писал(а):
Еще, проблема.
А это уж к автору.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
27-Янв-12 16:34
(спустя 1 час 1 мин., ред. 27-Янв-12 17:45)
simple.i писал(а):
omegalord писал(а):
И что значит надпись CTDB: could not be verified?
Не может быть проверен средствами программы. Типа "не шмогла".
Да, только вот, почему не смогла? Как я понимаю - причина в наличии прегапа, но в данном случае сообщения об этом не было, просто could not be verified и все, хотя я видел сообщения, где говрилось что диск не может быть проверен именно из за наличия прегапа. Вобщем как-то все запутанно.
simple.i писал(а):
omegalord писал(а):
Да, диски разные, но почему для разных дисков показывается , в обоих случаях,[832cf487] (11/11) и почему для одного диска пишется Has pregap length 00:00:32 - в четвертой строке, а для другого - Pregap length 00:00:32. во второй строке?
В одном рипе есть предзазор, а в другом нет - отсюда и разница. Программа дает информацию о том, что данный диск имеет предзазор такого-то размера.
Прошу прощения, все равно непонятно  Не могли бы объяснить более подробно?
Если прессинги разные, то, почему в обоих отчетах фигурирует строка [832cf487] (11/11) и почему, в обоих отчетах упоминается про прегап (ведь вы говорите, что в одном из дисков прегапа нет) и почему в одном случае информация о прегапе идет во 2й строке а в другом случае в 4й?
Честно говоря - вообще не очень понятна информация в отчете.
Наример:
abba - 1977 - the album.cue: CRC 22DA074A, AR: rip accurate (13/34), CTDB: verified OK, confidence 8
скрытый текст
[CUETools log; Date: 27.01.2012 17:08:10; Version: 2.1.2a]
Pregap length 00:00:33.
[CTDB TOCID: SmwX4lhs3uENyHUMxyyYViduPk0-] found.
[ CTDBID ] Status
[2ec48d28] (08/16) Has pregap length 00:00:00
[45c2fd87] (08/16) Accurately ripped
[AccurateRip ID: 000e5e72-006805dd-82096d09] found.
Track [ CRC ] Status
01 [22f96406] (13/34) Accurately ripped
02 [e50938ca] (13/34) Accurately ripped
03 [256e42a7] (13/34) Accurately ripped
04 [d96cae0e] (13/35) Accurately ripped
05 [fcd4c2c2] (13/35) Accurately ripped
06 [fc2497cd] (13/35) Accurately ripped
07 [851ee221] (13/34) Accurately ripped
08 [6635c975] (13/36) Accurately ripped
09 [64ce62f9] (13/36) Accurately ripped
Offsetted by -2812:
01 [295ca690] (00/34) No match but offset
02 [570e1bb4] (00/34) No match but offset
03 [f5e3904b] (00/34) No match but offset
04 [3890e9d0] (00/35) No match but offset
05 [20b5a180] (00/35) No match but offset
06 [740bb509] (00/35) No match but offset
07 [e6112d78] (00/34) No match but offset
08 [590e2589] (00/36) No match but offset
09 [5d49b692] (00/36) No match but offset
Offsetted by 1157:
01 [684905df] (21/34) Accurately ripped
02 [970592cf] (21/34) Accurately ripped
03 [97fc8bc1] (21/34) Accurately ripped
04 [905a481c] (22/35) Accurately ripped
05 [de969640] (00/35) No match but offset
06 [bb83ae18] (22/35) Accurately ripped
07 [231e217e] (21/34) Accurately ripped
08 [432f967c] (23/36) Accurately ripped
09 [fa200630] (23/36) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 91,3 [0E60C59B] [AB1E35DD] CRC32
01 87,2 [0C3BF28E] [B292C46C]
02 84,3 [24A3AAFD] [6285A314]
03 82,7 [9B938791] [6986D9F7]
04 86,9 [5541AC46] [20E0C622]
05 85,6 [EF0D662D] [A82A3F01]
06 90,8 [659B918E] [5D065472]
07 86,3 [6B024E7B] [85F263D0]
08 83,5 [F0F59AA7] [D8F55075]
09 91,3 [2E63B1FA] [E8347466]
Для данного диска DISCID 82096d09, CRC аудиоданных - 0E60C59B (W/O NULL - AB1E35DD). А вот что означает CRC 22DA074A ?
А что тогда означают вот эти, выделенные мной, цифры в отчете?
[ CTDBID ] Status
[ 2ec48d28] (08/16) Has pregap length 00:00:00
[ 45c2fd87] (08/16) Accurately ripped
Это тоже какие-то CRC? И почему их две - имеется ввиду что в базе есть рип с той же аудиочастью, но с прегапом.. так? Кстати 00:00:00 - разве это может считаться прегапом?
Может есть какая-то ссылка, где бы подробно разбирался отчет генерируемый cuetools (а за одно и особенности работы, такие как в упомянутых мной вопросах). Просто без более-менее внятного faq-а, таким как я разобраться во всем этом проблематично - не будешь же по каждой мелочи мучать народ на форуме.
|
|
|
|
Songs0fFailure
Стаж: 16 лет 4 месяца Сообщений: 2896
|
Songs0fFailure ·
27-Янв-12 17:36
(спустя 1 час 2 мин.)
omegalord писал(а):
Наример:
abba - 1977 - the album.cue: CRC 22DA074A, AR: rip accurate (13/34), CTDB: verified OK, confidence 8
откуда вообще это ? скрин можно ? 0_o
видел только это от Children of koRn - http://ilab.me/ilab/cuetools-log/
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
27-Янв-12 17:42
(спустя 6 мин.)
Songs0fFailure писал(а):
omegalord писал(а):
Наример:
abba - 1977 - the album.cue: CRC 22DA074A, AR: rip accurate (13/34), CTDB: verified OK, confidence 8
откуда вообще это ? скрин можно ? 0_o
видел только это от Children of koRn - http://ilab.me/ilab/cuetools-log/
Большое спасибо за ссылку - изучу на досуге.
Какой скрин (скрины) выложить? И , я так понимаю, что данный отчет чем-то смутил? Можно, для чайника, в двух словах, чем именно?
|
|
|
|
Songs0fFailure
Стаж: 16 лет 4 месяца Сообщений: 2896
|
Songs0fFailure ·
27-Янв-12 17:52
(спустя 10 мин.)
omegalord
Цитата:
А вот что означает CRC 22DA074A ?
Мне тоже интересно, к чему относится 22DA074A.
просто не пользуюсь ни пакетным режимом ни localDB. %)
я не понял где в CT эту строку видно, к чему она относится и когда появляется. -_-
|
|
|
|
simple.i
Стаж: 16 лет 9 месяцев Сообщений: 8442
|
simple.i ·
27-Янв-12 17:54
(спустя 1 мин.)
omegalord писал(а):
Да, только вот, почему не смогла?
Об этом, да и об остальном (почему, что и в какой строчке пишется, и почему так, а не иначе) Вам лучше расскажет gchudov, как автор программы. Я могу только догадываться. Например, разные строчки, чтобы легко было визуально отличить один вариант рипа от другого. Но это лишь догадки, как оно на самом деле...
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
27-Янв-12 18:10
(спустя 15 мин., ред. 27-Янв-12 18:10)
Songs0fFailure писал(а):
omegalord
Цитата:
А вот что означает CRC 22DA074A ?
Мне тоже интересно, к чему относится 22DA074A.
я не понял где в CT эту строку видно, к чему она относится и когда появляется. -_-
Помоему, в более ранних версиях не показывалось, а щас вот так:
Цитата:
просто не пользуюсь ни пакетным режимом ни localDB. %)
Завидую) Как раз одиночные рипы проверять вполне удобно, если же попытаться в пакетном режиме проверить десятки или сотни рипов, то, с нынешними возможностями интерфейса программы а так же тем видом в котором выводится сводный (по всем проверенным рипам) отчет - эта проверка просто теряет смысл, так как разгрести полученные результаты - нереально.
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
27-Янв-12 23:47
(спустя 5 часов, ред. 27-Янв-12 23:47)
simple.i
simple.i писал(а):
Об этом, да и об остальном (почему, что и в какой строчке пишется, и почему так, а не иначе) Вам лучше расскажет gchudov, как автор программы. Я могу только догадываться.
Думаю, вряд-ли он сможет это сделать на данном этапе "развития программы", так как это самое "развитие" уже начало принимать уродливые формы с момента появления функции "repair", а сейчас пик обострения, и многие имеющиеся в ней инструменты выполняют качественно свою задачу "дай бог" наполовину. Если так пойдёт дальше, то скоро ей пользоваться как простым конвертером - будет опасно.
|
|
|
|
NeoMaximus
Стаж: 17 лет 9 месяцев Сообщений: 67
|
NeoMaximus ·
29-Янв-12 10:51
(спустя 1 день 11 часов)
Ругается на отсутвие кодеков куда их нужно качать?
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
29-Янв-12 11:09
(спустя 18 мин.)
NeoMaximus писал(а):
Ругается на отсутвие кодеков куда их нужно качать?
Все нужные кодеры проще размешать в папке с программой, тогда в параметрах пути надо будет просто указать, например flac.exe, но можно и путь указать, где находится уже установленный кодировщик.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
29-Янв-12 17:52
(спустя 6 часов, ред. 29-Янв-12 17:52)
1. Вот такой рип:
EAC log
Exact Audio Copy V0.99 prebeta 3 from 28. July 2007
EAC extraction logfile from 19. December 2008, 20:31
Sandra / Everlasting Love
Used drive : TSSTcorpCDDVDW SH-S203B Adapter: 2 ID: 0
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No
Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Used output format : Monkey's Audio Lossless Encoder v3.99 DLL
Sample format : Normal Lossless Compression
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:59.62 | 0 | 17986
2 | 3:59.62 | 4:00.10 | 17987 | 35996
3 | 7:59.72 | 4:44.15 | 35997 | 57311
4 | 12:44.12 | 4:04.73 | 57312 | 75684
5 | 16:49.10 | 4:12.00 | 75685 | 94584
6 | 21:01.10 | 4:10.27 | 94585 | 113361
7 | 25:11.37 | 5:20.10 | 113362 | 137371
8 | 30:31.47 | 3:19.33 | 137372 | 152329
9 | 33:51.05 | 3:13.32 | 152330 | 166836
10 | 37:04.37 | 4:11.43 | 166837 | 185704
Range status and errors
Selected range
Filename E:\01 Audio\CD IMAGES\Sandra - Discography\1987 Everlasting Love\Sandra - Everlasting Love.ape
Peak level 100.0 %
Range quality 100.0 %
Test CRC 2623D648
Copy CRC 2623D648
Copy OK
No errors occurred
AccurateRip summary
Track 1 accurately ripped (confidence 1) [D99F739F]
Track 2 not present in database
Track 3 not present in database
Track 4 not present in database
Track 5 accurately ripped (confidence 1) [836F8A66]
Track 6 accurately ripped (confidence 1) [99FA82A4]
Track 7 not present in database
Track 8 not present in database
Track 9 not present in database
Track 10 accurately ripped (confidence 1) [7A715020]
4 track(s) accurately ripped
6 track(s) not present in the AccurateRip database
Some tracks could not be verified as accurate
End of status report
accurip
[CUETools log; Date: 28.01.2012 11:09:20; Version: 2.1.2a]
Offset applied: 99999
[CTDB TOCID: t7nsfWK3Jx8VsOUfgoBZJpaQYHI-] disk not present in database.
[AccurateRip ID: 000fd374-007e8d7a-6509ac0a] found.
Track [ CRC ] Status
01 [62e303eb] (0/0) No match
02 [042236cb] (0/0) No match
03 [7dd7d42a] (0/0) No match
04 [d086df8e] (0/0) No match
05 [1fc669d8] (0/0) No match
06 [7fb0b133] (0/0) No match
07 [b412b5c3] (0/0) No match
08 [5c4d395a] (0/0) No match
09 [30954cae] (0/0) No match
10 [2bb6785d] (0/0) No match
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [A0C6AEF5] [C9E2E772] [2623D648]
01 97,0 [223D90DD] [EDC29B31]
02 100,0 [1592F882] [5CA67683]
03 98,9 [B0054188] [6B8277F9]
04 84,0 [174A7416] [D9F4F305]
05 99,7 [9F394696] [BD30C79C]
06 91,0 [1EF6226F] [033F0D31]
07 100,0 [B5091890] [855F1B8C]
08 90,0 [A0B038A4] [58935128]
09 100,0 [E3F45635] [7AE54EA4]
10 86,1 [17AEB120] [FDCFD28C]
Это сразу в помойку, или возможны какие то варианты "лечения" (если не для данного случая, то хотя бы в теории, для чего-то подобного)
2. В связи с этим еще хотелось бы поинтересоваться у присутствующих - если вам случается пофиксить рип функцией "repair" то что выделаете с логом - правите или оставляете прежним? Возможно, как-то помечаете рип - дескать была исправлена ошибка и поэтому данные не соответствуют логу?
3. У кого-то есть опыт использования FLACCL? Аппаратная поддержка только для кодировки работает или и для декодировки тоже? При проверке больших количеств рипов аппаратное декодирование было бы полезным.
Далее - возможны ли какие-то проблемы связанные с порчей аудиоданных при кодировании? Вот здесь об этом что-то такое мелькает в комментариях.
И что касаемо самой видеокарты - вот здесь для ATI указана только линейка 5xxx - как я понимаю и 6xxx - тоже подойдет?
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
29-Янв-12 18:43
(спустя 51 мин., ред. 29-Янв-12 18:43)
omegalord писал(а):
bad boys blue - house of silence.flac.cue: CRC 4FFB2EF3, AR: rip not accurate (0/3), CTDB: verified OK, confidence 1
(1/1) Accurately ripped
Получается, что CTDB этот рип добавлен через CUERipper и считается правильным
Уровня доверия (1/1) недостаточно, чтобы считать рип правильным. Уровень доверия 1 будет у любого кривого рипа, если он будет занесён в базу. Правильный рип - это где хотя бы уровень доверия 2, чем больше - тем лучше. Более того, в данном случае результат из базы AR (0/3) позволяет довольно уверенно говорить, что рип кривой.
omegalord писал(а):
Далее. 2 прессинга одного и того же альбома.
sandra - mirrors.cue: CRC 3F995D8F, AR: rip accurate (17/17), CTDB: verified OK, confidence 11
mirrors [flac].cue: CRC 10017570, AR: offset 594, rip accurate (1/1), CTDB: could not be verified
Что значит CTDB: could not be verified и с прегапами совсем запутанно - получается, что аудиочасть одна и таже, только в одном из вариантов альбома нет прегапа?
Да, аудиочасть одинаковая, судя по контрольным суммам AR. CTDB проверить вариант без прегапа не смогла, потому что в CTDB 1.0 не было возможности сравнивать рипы с разными прегапами. В CTDB 2.0 этой проблемы нет.
omegalord писал(а):
И еще, для второго альбома, вышеприведенный отчет можно получить только, если проверять этот альбом отдельно, а проверка в пакетном режиме дает следующий отчет:
Тут логика работы простая: в пакетном режиме программе запрещено выдавать лишние окна, поэтому если без помощи пользователя найти лог не удалось, то альбом обрабатывается без лога. Хватать первый попавшийся файл с расширением .log не хочу, потому что часто попадается какой-нибудь audiochecker.log или еще что-нибудь такое. Единственное исключение - когда в папке есть лог от свежей версии EAC (в котором есть правильный TOC). В этом случае программа легко догадывается, что это именно лог EAC, причем именно от этого диска.
omegalord писал(а):
Да, диски разные, но почему для разных дисков показывается , в обоих случаях, [832cf487] (11/11) и почему для одного диска пишется Has pregap length 00:00:32 - в четвертой строке, а для другого - Pregap length 00:00:32. во второй строке?
[832cf487] (11/11) - это информация о рипе в базе, а не о вашем рипе. В обоих случаях в базе нашелся один и тот же релевантный рип в базе. Но в одном случае он соответствовал вашему (Accurately ripped), а во втором случае сравнить его с вашим не удалось, потому что разный размер прегапа. Во второй строке пишется прегап вашего рипа. А в четвёртой строке - прегап диска в базе, если он отличается от вашего. Ждите CTDB 2.0, где проблемы со сравнением дисков с разными прегапами не будет, и отчет будет больше похож на привычный отчет AR.
omegalord писал(а):
Проверил папку с рипами в пакетном режиме. Один из рипов - "crc mismatch" из за чего вся толпа потенциалльных двойников (уже проверенных) тусит вместе с ним в подразделе "not yet verified".
Что еще хуже, что стоит только покинуть это окно, как, информация о том, что данный рип "crc mismatch" - исчезает, и показывается уже просто как "never verified"
Попробую исправить, когда руки дойдут.
omegalord писал(а):
Три отчета трансформировались в "never verified". Жмем кнопку "поехали" (с галочкой в чекбоксе "skip recently verified") - отчет без всяких проверок, в ту же секунду, возвраващется к виду "а". При этом все рипы, все так же остаются в подразделе "not yet verified".
Не совсем понял из картинки что тут происходит. Тут каким-то образом каждый их трёх рипов по два раза присутствует с одинаковым путём? Или они на разных жестких дисках?
|
|
|
|
Songs0fFailure
Стаж: 16 лет 4 месяца Сообщений: 2896
|
Songs0fFailure ·
29-Янв-12 18:48
(спустя 4 мин.)
omegalord
wtf ?
Цитата:
Offset applied: 99999
ноль поставьте и проверьте заново рип.
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
29-Янв-12 19:13
(спустя 25 мин., ред. 29-Янв-12 19:13)
omegalord писал(а):
Для данного диска DISCID 82096d09, CRC аудиоданных - 0E60C59B (W/O NULL - AB1E35DD). А вот что означает CRC 22DA074A ?
Это внутренняя CRC, используемая только в LocalDB. Подробнее, это CRC32 образа диска за вычетом некоторого количества сэмплов в начале и конце диска (т.е. в отличие от обычной CRC32 должна совпадать для рипов, сделанных приводами с разными смещениями). Именно при совпадении данной CRC диски считаются клонами с точки зрения LocalDB. Наверное я её зря печатаю, незачем мучать пользователей еще одной нестандартной CRC
omegalord писал(а):
[2ec48d28] (08/16) Has pregap length 00:00:00
[45c2fd87] (08/16) Accurately ripped
Это тоже какие-то CRC? И почему их две - имеется ввиду что в базе есть рип с той же аудиочастью, но с прегапом.. так?
А это уже внутренние CRC CTDB Причем не для вашего рипа, а для имеющихся в базе двух записи для этого диска. С той же аудиочастью или нет, неизвестно, но одна с прегапом, а другая - без. pregap length 00:00:00 - это отсутствие прегапа Я уже понял, что такой формат отчета слабо читаем, и в CTDB 2.0 по умолчанию отчет будет выглядеть как отчеты AccurateRip. Но в процессе разработки базы такой формат отчета был очень полезен - если что не так, пользоватли присылали логи, и мне было легко разобраться.
omegalord писал(а):
Это сразу в помойку, или возможны какие то варианты "лечения" (если не для данного случая, то хотя бы в теории, для чего-то подобного)
Проверить этот рип толком пока не удалось, потому что в базе AR есть только часть треков, но вообще, судя по логу EAC, рип выглядит хорошим. Отчет CUETools, как верно заметили выше, кривой из-за выставленного при проверке смешного оффсета.
omegalord писал(а):
Аппаратная поддержка только для кодировки работает или и для декодировки тоже?
Только для кодировки. Декодирование врядли можно серьёзно ускорить за счет GPU.
omegalord писал(а):
Далее - возможны ли какие-то проблемы связанные с порчей аудиоданных при кодировании?
Да. Особенно если видеокарта разогнана, перегревается или просто плохо сделана. Видеокартами для вычислений пока пользуются редко, поэтому их не так тщательно тестируют на качество. Если у вас глючит процессор, то вы это достаточно быстро заметите. А если видеокарта - ну будут пара пикселей не совсем правильного цвета, кто это заметит. Поэтому настоятельно рекомендуется кодировать с ключем -verify, это чуть-чуть замедляет процесс, но зато вы можете быть уверены что в случае ошибки при кодировании вы о ней узнаете.
omegalord писал(а):
для ATI указана только линейка 5xxx - как я понимаю и 6xxx - тоже подойдет?
Да.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1386
|
omegalord ·
29-Янв-12 20:08
(спустя 54 мин.)
gchudov Благодарю за ответы! Теперь стало понятнее.
gchudov писал(а):
omegalord писал(а):
Три отчета трансформировались в "never verified". Жмем кнопку "поехали" (с галочкой в чекбоксе "skip recently verified") - отчет без всяких проверок, в ту же секунду, возвраващется к виду "а". При этом все рипы, все так же остаются в подразделе "not yet verified".
Не совсем понял из картинки что тут происходит. Тут каким-то образом каждый их трёх рипов по два раза присутствует с одинаковым путём? Или они на разных жестких дисках?
Диск один а папки,на самом деле, разные, (весь путь в скриншот не поместился) просто какие то конечные папки совпадают. Происходит такая петрушка что диски нормально проверяются но все равно оcтаются в разделе "not yet verified" причем для 3х дисков строка проверки сразу скидывается к виду "never verified". Если запустить проверку с активированным чекбоксом "skip recently verified" то для этих 3х дисков, в ту же секунду строки вида "never verified" преобразуются к полученным при проверке данным но диски все равно остаются в разделе "not yet verified" и т.д. - замкнутый круг короче У меня так и не получилось победить эту группу потенциальных двойников и я их пока удалил из базы.
gchudov писал(а):
omegalord писал(а):
Это сразу в помойку, или возможны какие то варианты "лечения" (если не для данного случая, то хотя бы в теории, для чего-то подобного)
Проверить этот рип толком пока не удалось, потому что в базе AR есть только часть треков, но вообще, судя по логу EAC, рип выглядит хорошим. Отчет CUETools, как верно заметили выше, кривой из-за выставленного при проверке смешного оффсета.
Да, с оффсетом фигня какая-то вышла, наверно кошка по клавиатуре топталась -:)
Проверил с нормальным оффсетом - уже, конечно, получше результат, данные указанные в логе совпадают:
скрытый текст
[CUETools log; Date: 29.01.2012 20:33:57; Version: 2.1.2a]
[CTDB TOCID: t7nsfWK3Jx8VsOUfgoBZJpaQYHI-] disk not present in database.
[AccurateRip ID: 000fd374-007e8d7a-6509ac0a] found.
Track [ CRC ] Status
01 [d99f739f] (0/0) No match but offset
02 [6bbfcfbc] (0/0) No match but offset
03 [d706f4d2] (0/0) No match but offset
04 [dfca1b9e] (0/0) No match but offset
05 [836f8a66] (0/0) No match but offset
06 [99fa82a4] (0/0) No match but offset
07 [d84bef89] (0/0) No match but offset
08 [21b5f8fc] (0/0) No match but offset
09 [d2576d3c] (0/0) No match but offset
10 [7a715020] (0/0) No match but offset
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [2623D648] [B0944145] CRC32
01 97,0 [DE43DA3E] [88A77236]
02 100,0 [215FC32D] [AB34A4CE]
03 98,9 [E39179F4] [E5472411]
04 84,0 [432596BE] [EB774792]
05 99,7 [C2984E67] [B09FA8AE]
06 91,0 [A0CF84BB] [CB7143AE]
07 100,0 [26E8C0CB] [422FEE1E]
08 90,0 [32FFB007] [989C42FB]
09 100,0 [792B74E9] [70DA3346]
10 86,1 [77B5A99F] [F432D629]
но, собственно, смутил (в независимости от оффсета) такой момент, что при проверке получаем нулевой результат а судя по логу - там чета находилось в базе.. получается что аудиоданные изменяли? или из базы тот рип пропал.. такое возможно?
Вот еще рип.. тут уже все норм с оффсетом, но данные в логе не совпадают с расчетными.
EAC
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009
Отчёт EAC об извлечении, выполненном 29. июня 2010, 0:18
Sandra / 1988 - Into A Secret Land (Japan)
Дисковод: MATSHITABD-MLT UJ-210S Adapter: 0 ID: 0
Режим чтения : Достоверность
Использование точного потока : Да
Отключение кэша аудио : Да
Использование указателей C2 : Нет
Коррекция смещения при чтении : 102
Способность читать области Lead-in и Lead-out : Нет
Заполнение пропущенных сэмплов тишиной : Да
Удаление блоков с тишиной в начале и конце : Нет
При вычислениях CRC использовались нулевые сэмплы : Да
Интерфейс : Встроенный Win32-интерфейс для Win NT/2000
Выходной формат : Внутренние WAV-операции
Формат сэмплов : 44.100 Гц; 16 бит; стерео
TOC извлечённого CD
Трек | Старт | Длительность | Начальный сектор | Конечный сектор
---------------------------------------------------------------------
1 | 0:00.37 | 4:46.40 | 37 | 21526
2 | 4:47.02 | 4:11.00 | 21527 | 40351
3 | 8:58.02 | 4:04.45 | 40352 | 58696
4 | 13:02.47 | 5:36.53 | 58697 | 83949
5 | 18:39.25 | 3:18.52 | 83950 | 98851
6 | 21:58.02 | 4:11.45 | 98852 | 117721
7 | 26:09.47 | 3:44.70 | 117722 | 134591
8 | 29:54.42 | 3:28.50 | 134592 | 150241
9 | 33:23.17 | 3:59.05 | 150242 | 168171
Характеристики диапазона извлечения и сообщения об ошибках
Выбранный диапазон
Имя файла J:\temp\1988 - Into A Secret Land (Japan).wav
Пиковый уровень 73.4 %
Качество диапазона 100.0 %
CRC теста E94D809B
CRC копии E94D809B
Копирование... OK
Ошибок не произошло
AccurateRip: сводка
Трек 1 нет в базе данных
Трек 2 нет в базе данных
Трек 3 нет в базе данных
Трек 4 нет в базе данных
Трек 5 нет в базе данных
Трек 6 нет в базе данных
Трек 7 нет в базе данных
Трек 8 нет в базе данных
Трек 9 нет в базе данных
Ни одного трека нет в базе AccurateRip
Конец отчёта
accurip
[CUETools log; Date: 28.01.2012 21:19:18; Version: 2.1.2a]
Pregap length 00:00:37.
[CTDB TOCID: .DbXYVLmUnQZ4is0lOx0sexHa8g-] disk not present in database.
[AccurateRip ID: 000d569d-0060d6e1-6808c209] disk not present in database.
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 72,8 [B56B93FE] [ACD51A6B] [E94D809B]
01 72,8 [8E54C3D7] [D94AA56B]
02 71,8 [18D81FFF] [29F32DA2]
03 72,5 [2DB7A165] [F1917F09]
04 71,2 [9F5CF2F5] [EA153681]
05 71,3 [1C645559] [EED2349B]
06 72,5 [0766DF16] [A608068A]
07 70,7 [9E44D03F] [5C3023FC]
08 70,8 [E7A4C6CB] [C819E8B2]
09 71,1 [F535C680] [894E4862]
Хотелось бы для себя уяснить, на будущее, можно ли такие рипы привести к аутентичному виду, или тут только удалять.. ведь наверно не получится определить - был изменен лог или аудиоданные?
gchudov писал(а):
omegalord писал(а):
Аппаратная поддержка только для кодировки работает или и для декодировки тоже?
Только для кодировки. Декодирование врядли можно серьёзно ускорить за счет GPU.
Жаль. ( У меня Core Cuad 3 Ггц при провеке flac рипа процессор грузится на 30-40%, дефрагментированная папка на 50 Гб проверялась больше часа. (
|
|
|
|
Fossman
Стаж: 18 лет 4 месяца Сообщений: 3570
|
Fossman ·
29-Янв-12 20:36
(спустя 28 мин.)
Тут некоторые ругают автора CUE Ripper. А я наоборот хочу похвалить, поскольку это его собственная программа. И программа неплохая на мой взгляд. Огорчет только то, что она является заложником CUEToos, а поэтому развивается медленнее, чем могда бы и обновления редки. Если бы она была отдельной в части обновлений (совместную работу с CT можно и не отменять), то это бы, мне думается благотворно сказалось на ее более быстром развитии. А сейчас, чтобы увидеть изменение ерундовой загогулины в CR надо ждать, когда дозреет CT. Хотя практически это совсем не обязательно: мажорные обновления обоих программ могут быть и совместными, а вот минорные, могли бы быть и раздельными.
Из функционала хотелось бы увидеть режим brust&secure (подобно t&c в EAC, но на мой взгляд, более практически полезный нежели t&c).
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
29-Янв-12 23:02
(спустя 2 часа 25 мин.)
Fossman
Fossman писал(а):
Тут некоторые ругают автора CUE Ripper. А я наоборот хочу похвалить
Да, конечно-же надо похвалить, а как иначе, особенно похвалить должен его автор ЕАС, за то что он подгоняет работу своей базы, которая должна была служить своему рипперу, под его риппер. Таким образом, работа его риппера с базой будет на таком-же уровне как и стороннего.
Fossman писал(а):
Огорчает только то, что она является заложником CUEToos
Она не заложник CUETools, а заложник автора, ему важнее продвижение своей базы для исправления поделок криворуких пользователей.
|
|
|
|
Stripakulina
Стаж: 16 лет 10 месяцев Сообщений: 1082
|
Stripakulina ·
30-Янв-12 00:07
(спустя 1 час 5 мин.)
Cornerstone писал(а):
Да, конечно-же надо похвалить, а как иначе, особенно похвалить должен его автор ЕАС, за то что он подгоняет работу своей базы, которая должна была служить своему рипперу, под его риппер.
Вообще-то, база AccurateRip автору EAC'а не принадлежит. Он сам ей всего лишь пользуется. С разрешения разработчика. А создал её совсем другой человек. И он дал автору CueRipper'а точно такое же право на использование. Так что, автор EAC'а никак не пострадал.
Cornerstone писал(а):
Она не заложник CUETools, а заложник автора, ему важнее продвижение своей базы для исправления поделок криворуких пользователей.
Не слишком ли категоричное суждение? Что значит "криворуких"?
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
30-Янв-12 00:24
(спустя 17 мин., ред. 30-Янв-12 00:24)
Stripakulina
Stripakulina писал(а):
Вообще-то, база AccurateRip автору EAC'а не принадлежит
А, где хоть слово про AR? Вы вначале в тему впишитесь, а потом пишите! Я смотрю, Вы настолько углублённо знаете английский, что имеете смелость в своих постах указывать людям на его плохое знание, если хотите, то прямо в этой теме найду Ваш пост, так вот, вначале научитесь читать по русски, а потом уже всё остальное.
|
|
|
|
Stripakulina
Стаж: 16 лет 10 месяцев Сообщений: 1082
|
Stripakulina ·
30-Янв-12 04:03
(спустя 3 часа, ред. 30-Янв-12 04:03)
Cornerstone
Ну, так уж вы хитророждённо фразу построили. Надо было чётко написать, что gchudov свою базу CTDB заполняет через EAC.
Cornerstone писал(а):
Я смотрю, Вы настолько углублённо знаете английский
А Вы ещё и злопамятны. Только не Вам у меня экзамен на знание английского языка принимать. Я тогда не стал продолжать, потому что махнул рукой. Не люблю в таком недружелюбном тоне беседовать.
А вообще, только Рунету свойственна такая агрессия. Менталитет, видимо, сказывается.
Так что, продолжайте рассказывать gchudovу, что он вам ещё должен сделать, и какую ересь должен немедленно убрать. Томас Торквемада аплодирует Вам стоя.
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
30-Янв-12 18:54
(спустя 14 часов, ред. 30-Янв-12 18:54)
Stripakulina
Stripakulina писал(а):
А Вы ещё и злопамятны. Только не Вам у меня экзамен на знание английского языка принимать. Я тогда не стал продолжать, потому что махнул рукой. Не люблю в таком недружелюбном тоне беседовать
Я не злопамятный, просто у меня память хорошая!
Специально для Вас
Начнём с того, что, это я не захотел дальше развивать фразу сказанную Вами вот в этом посту и заключённую под сполером:-"Образованный человек должен знать как минимум один иностранный язык. минус гугол." в ответ на очень остроумную реплику одного из пользователей в которой был заключён вопрос о сути написанного на англоязычном сайте, ссылку на который Вы привели. И даже после, прямым текстом заданного повторно этого-же вопроса, Вы игнорировали просьбу и не ответили на него, или сделали вид что не заметили. Если Вам тяжело в нескольких предложениях передать суть прочитанного, причём, передать на родном языке, или понять изложенное в предложении, которое по своей структуре немного сложнее чем "Мама мыла раму", с восклицаниями после этого -
Stripakulina писал(а):
Ну, так уж вы хитророждённо фразу построили
то такой человек в большей степени не образован, чем тот, который не владеет ни одним иностранным языком. Или за этим стоит нечто большее, граничащее с пренебрежением к присутствующим на одном форуме с вами софорумчанам, о чём очень характерно говорит вот этот Ваш пост
|
|
|
|
