|
|
|
Fossman
Стаж: 18 лет 4 месяца Сообщений: 3570
|
Fossman ·
12-Фев-12 23:04
(13 лет 7 месяцев назад)
omegalord писал(а):
Хотя лично я стараюсь фубаром для конвертирования не пользоваться вообще - пару лет назад в нем стабильно возникала проблема (и в официальных версиях и в сборках) при конвертировании файлов с определенным набором тегов когда CRC конечных аудиоданных не совпадали с исходными (помоему как раз в этой теме я задавал вопрос по этому поводу), в то время как CUETools конвертировал все корректно и без ошибок.
Бедный, вы, бедный... Особенно если учесть, что foobar2000 использует для конвертации родные кодеки от производителей соответствующего кодека, являясь фктически фронтэндом (графической оболочкой) для соответствующего энкодера. В таком случае, если верить вашим "изысканиям", ошибку допостили сами производители кодеков, сделав кривые энкодеры.
Но это еще не все! Самое замечательное, согласно опять же вам, cuetools (также использующий кодеки не собственного производства, а от тех же самых производителей кодеков) - "исправляет" эти самые "кривые" кодеки выдавая правильный, то есть "исправленный" вариант кодировния. Какой волшебный cuetools!
___________________
Вменяемым пользователям
Вышенаписанное относится к тому, чтобы хорошенько подумать, прежде чем прислушиваться и тем более следовать чьим-то "умным и квалифицированным" советам и рассуждениям.
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
13-Фев-12 09:24
(спустя 10 часов)
К сожалению, вы неправы.
Во первых, графические оболочки, такие как фубар, могут вносить ошибки, потому что между декодером старого формата и энкодером нового аудиоданные лежат в буферах оболочки. Например, когда вы конвертируете из .ape во .flac, запускаются штатный декодер .ape и штатный энкодер .flac, результат работы декодера кладётся в буфер фубара, потом к буферу могут применяться например DSP эффекты, или буфер может повреждаться из-за ошибок, а потом из этого буфера уже потенциально изменённые данные скармливаются энкодеру.
Во вторых, cuetools использует в том числе кодеки собственного производства.
|
|
|
|
Fossman
Стаж: 18 лет 4 месяца Сообщений: 3570
|
Fossman ·
13-Фев-12 09:33
(спустя 8 мин., ред. 13-Фев-12 09:33)
gchudov писал(а):
Во первых, графические оболочки, такие как фубар, могут вносить ошибки, потому что между декодером старого формата и энкодером нового аудиоданные лежат в буферах оболочки. Например, когда вы конвертируете из .ape во .flac, запускаются штатный декодер .ape и штатный энкодер .flac, результат работы декодера кладётся в буфер фубара, потом к буферу могут применяться например DSP эффекты, или буфер может повреждаться из-за ошибок, а потом из этого буфера уже потенциально изменённые данные скармливаются энкодеру.
Это вы неправы. Поскольку речь шла о конвертировании (преобразование одного формата в другой), а не о аудиотрансформации (то есть, редактировании аудио)
gchudov писал(а):
Во вторых, cuetools использует в том числе кодеки собственного производства.
Какие именно? И Алгоритм их оригинален (то есть написан вами)?
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
13-Фев-12 09:49
(спустя 16 мин.)
Fossman писал(а):
Поскольку речь шла о конвертировании (преобразование одного формата в другой), а не о аудиотрансформации (то есть, редактировании аудио)
Я и говорил о конвертировании.
Fossman писал(а):
gchudov писал(а):
Во вторых, cuetools использует в том числе кодеки собственного производства.
Какие именно? И Алгоритм их оригинален (то есть написан вами)?
Например кодеки libFlake и libAlac. Алгоритмы частично базируются на других проектах с открытым кодом, в первом случае это flake (c) Justin Ruggles, во втором это код из ffdshow (c) Jaikrishnan Menon, но в обоих случаях существенно переработаны в сторону ускорения работы и увеличения степени сжатия.
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
13-Фев-12 11:20
(спустя 1 час 31 мин., ред. 13-Фев-12 11:20)
gchudov писал(а):
но в обоих случаях существенно переработаны в сторону ускорения работы и увеличения степени сжатия.
Поясните еще раз, какое ускорение и увеличение степени сжатия, на примере libALAC?
Не хотелось опять начинать разговор, но я не увидел даже доли правды того, что было просчитано на гидрогене. Проделал немало экспериментов на скорость и степень сжатия Refealac и LibALAC, все тесты не в пользу libALAC. И что бы в этом убедится достаточно самому провести хотя бы пару- тройку конвертаций.
Может он имеет преимущества на какой то отдельно взятой конфигурации железа? Назовите тогда конфигурацию.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1387
|
omegalord ·
13-Фев-12 11:30
(спустя 9 мин., ред. 13-Фев-12 11:30)
Olyacherry7 писал(а):
omegalord
я конвертирую (режу на треки) только во FLAC из APE или FLAC образов. Ну ещё из FLAC делаю .mp3 для тех устройств, которые не поддерживают lossless форматы.
Сомневаюсь что тип lossless кодека имел какое-то решающее значение. Был бы flac или ape (вместо wv) с тем вшитым cue файлом - была бы та же ошибка при конвертировании в фубаре.
Хотя это относительно давно было, может сейчас что-то поменялось, я не проверял, так как функцию конвертирования в фубаре использую, практически, только для винил-рипов 24-96,24-192 которые CUETools не понимает, а для любых телодвижения связанных с конвертированием - использую CUETools - мне так и удобнее и спокойнее.
|
|
|
|
Olyacherry7
Стаж: 13 лет 11 месяцев Сообщений: 119
|
Olyacherry7 ·
13-Фев-12 19:55
(спустя 8 часов, ред. 13-Фев-12 19:55)
Цитата:
Например кодеки libFlake и libAlac. Алгоритмы частично базируются на других проектах с открытым кодом, в первом случае это flake (c) Justin Ruggles, во втором это код из ffdshow (c) Jaikrishnan Menon, но в обоих случаях существенно переработаны в сторону ускорения работы и увеличения степени сжатия.
Да, работает побыстрее чем через фубар (на глаз  ), даже без сжатия, я без сжатия всегда режу образы на треки.
Цитата:
а для любых телодвижения связанных с конвертированием - использую CUETools - мне так и удобнее и спокойнее.
Мне фубаром больше понравилось, а телодвижения всегда были с CUETools 
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
13-Фев-12 20:14
(спустя 18 мин.)
Olyacherry7 писал(а):
а, работает побыстрее чем через фубар
CUETools по определению не может работать быстрее.
Olyacherry7 писал(а):
Мне фубаром больше понравилось, а телодвижения всегда были с CUETools
Телодвижения в foobar2000 будет намного больше, когда в пакетном режиме надо будет что- то сделать.
|
|
|
|
Fossman
Стаж: 18 лет 4 месяца Сообщений: 3570
|
Fossman ·
13-Фев-12 23:07
(спустя 2 часа 53 мин.)
gchudov писал(а):
Я и говорил о конвертировании.
Использование любых фильтров - редактирование аудио, а не конвертация:
gchudov писал(а):
к буферу могут применяться например DSP эффекты
Так что вам стоит определиться сначала, а потом уже заводить разговор.
gchudov писал(а):
Например кодеки libFlake и libAlac.
Отлично.
Таким образом из сказанного вами напрямую следует, что разработчики форматов (и создатели соответствующих кодеков), в частности FLAC и ALAC допустили ошибки в своих алгоритмах, приводящие к ошибкам кодирования. А вы написав эти алгоритмы с нуля, реализовали их в программном виде в более совершенном виде и безошибочно. Я правильно понимаю?
gchudov писал(а):
Алгоритмы частично базируются на других проектах с открытым кодом, в первом случае это flake (c) Justin Ruggles, во втором это код из ffdshow (c) Jaikrishnan Menon
Ааааа! Все-таки алгоритмы таки- не ваши. А я как вы заметили спрашивал про ваши. Значит ваших там нет, как я и сказал выше. Хорошо. Значит авторы этих алгоритмов, перечисленные вами, создали энкодеры, более совершенные, чем авторы форматов, и соответственно безошибочные, в отличие от оригинальных (от разработчиков), соответствующих форматов. Это вы хотели сказать?
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
14-Фев-12 01:51
(спустя 2 часа 43 мин., ред. 14-Фев-12 01:51)
Fossman писал(а):
Использование любых фильтров - редактирование аудио, а не конвертация:
В фубаре есть одна кнопка, и называется она "конвертировать". В настройках этой операции можно применять фильтры. А можно и не применять. Всё равно данные будут будут проходить через внутренний буфер программы, поэтому в теории на этой стадии возможны ошибки, даже при использовании надёжных кодеков. Это касается любой оболочки над кодеками, в том числе cuetools. Единственная известная мне на текущий момент ошибка при конвертации в фубаре связана не с кодеками, а с самим фубаром - он выкидывает прегап, даже при конвертации из образа в образ.
Fossman писал(а):
Таким образом из сказанного вами напрямую следует, что разработчики форматов (и создатели соответствующих кодеков), в частности FLAC и ALAC допустили ошибки в своих алгоритмах, приводящие к ошибкам кодирования. А вы написав эти алгоритмы с нуля, реализовали их в программном виде в более совершенном виде и безошибочно. Я правильно понимаю?
Нет. Я всего лишь указал вам на два неверных утверждения - что якобы оболочки не могут вносить ошибок и что якобы cuetools пользуется только стандартными кодеками.
Fossman писал(а):
Ааааа! Все-таки алгоритмы таки- не ваши.
Авторство, как почти всегда бывает в продуктах с открытым кодом, совместное. 99% кода этих кодеков написано тем не менее мной, и в случае наличия ошибок я беру за них ответственность на себя. Вот что я этим хотел сказать.
Вы уж конечно извините, господин Fossman, но у меня складывается ощущение что вы в этот топик зашли просто потроллить, судя по степени вашего знакомства с материалом, безапелляционности ваших утверждений, и вежливостью общения.
megane68 писал(а):
Поясните еще раз, какое ускорение и увеличение степени сжатия, на примере libALAC?
Прошу заметить, что refALAC опубликован недавно. libALAC был существенно быстрее того кода, на котором был основан.
refALAC конкурирует на уровне, тесты можно посмотреть например тут: http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=91530&view=findpost&p=775216
Там выходит, что libALAC немного медленнее чем refALAC, зато существенно лучше сжимает.
На моих тестах (core i5-2410M x64) libALAC -0 быстрее, чем refALAC без параметров, и сжимает сильнее:
Код:
CUETools.ALACEnc, Copyright (C) 2009 Gregory S. Chudov.
Based on ffdshow ALAC audio encoder
Copyright (c) 2008 Jaikrishnan Menon, <realityman@gmx.net>
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename : D:\temp\new\[1994] Meddle (Remastered 1992)\Pink Floyd - Meddle (Remastered 1992).wav
File Info : 44100kHz; 2 channel; 16 bit; 00:46:52.0670000
Results : 107.09x; 00:00:26.2585019
Итого, 233259457 байт при скорости 107.09x
Код:
refalac 0.40
Pink Floyd - Meddle (Remastered 1992).wav
[100.0%] 46:52.066/46:52.066 (88.5x), ETA 0:00.000
124012140/124012140 samples processed in 0:31.792
Overall bitrate: 668.625kbps
Итого, 235160081 байт при скорости 88.5x
refALAC с параметром --fast, впрочем, быстрее libALAC, но сжимает совсем плохо:
Код:
refalac 0.40
Pink Floyd - Meddle (Remastered 1992).wav
[100.0%] 46:52.066/46:52.066 (151.5x), ETA 0:00.000
124012140/124012140 samples processed in 0:18.564
Overall bitrate: 680.004kbps
Итого, 239159880 байт при скорости 151.5x
Вывод: можно подумать над тем, чтобы подкорректировать нулевой уровень сжатия libALAC в сторону снижения сжатия и увеличения скорости, но стоит ли ускорение на 40% потери 6 мегабайт на альбом... Для меня гораздо важнее производительность на более высоких степенях сжатия.
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
14-Фев-12 01:55
(спустя 4 мин., ред. 14-Фев-12 01:55)
Так я об этом графике и говорю как раз.
На счет сжатия я написал уже выше, надеюсь читали результаты моих опытов на тот момент. Во первых разница сжатия не настолько уж большая, а потеря скорости просто огромная. Во вторых нужно понять, что ALAC является форматом Apple, а следовательно расчитан для портативных плееров в том числе. Думаю для них выбрано оптимальное сжатие в родном кодеке, и существует лишь два варианта сжатия - Normal и Fast. Поэтому эксперименты со степенью сжатия в ALAC думаю не очень то актуальны, по крайней мере на данный момент.
Лично мое мнение, что после выхода исходного кода ALAC, надо не карпеть над усовершенствованием никому не нужного стороннего алгоритма, а усовершенствованием родного. Что в принципе и делает автор Refalac. Вы же не переделываете алгоритм FLAC, все его модификации скорее связаны с различного рода оптимизацией.
Все остальные действия не связанные с усовершенствованием родного кодека ведут лишь к ненужной неразберихе и возможным багам в работе яблочных девайсов с этим алгоритмом.
gchudov писал(а):
Похоже там сравнивали, правда, рыбу и мясо - в случае refALAC использовалось приложение командной строки, в случае libALAC - оболочка cuetools, которая работает чуть медленее.
Я сравнивал именно результаты CUETools. Все результаты не в пользу LibALAC.
gchudov писал(а):
На моих тестах (core i5-2410M x64) libALAC -0 быстрее:
Ну так это только на Ваших почему то.
gchudov писал(а):
Для меня гораздо важнее производительность на более высоких степенях сжатия.
Вы просто никогда видимо не пользовались айподами и айфонами. Не надо ничего делать. Это фанатизм просто какой то.
Я понимаю стремление хакнуть закрытую программу, но когда начинают хакать открытую программу это уже перебор с фанатизмом. Напоминает байку, когда один приятель попросил другого сделать ему платный браузер, что бы было что хакнуть.
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
14-Фев-12 02:36
(спустя 40 мин., ред. 14-Фев-12 02:51)
Начнём с того, что код, который выложил Apple - это не тот код, который они используют сами. Это демонстрационный код, выложенный чтобы было понятно как устроен формат. В том виде, в котором они его выложили - он был достаточно медленным, неудобным к использованию и содержал ошибки. К пониманию структуры формата он ничего нового не добавил по сравнению с тем кодом, на котором я основывал libALAC. Для промышленного использования всё равно приходится писать свой код, на базе того или этого - неважно. Так что между моей работой над libALAC и работой авторов refALAC нет никакой принципиальной разницы. Такое ощущение, что вы приписываете исходному коду некие мистические нематериальные свойства, типа "души" алгоритма, и для вас становится важно, при написании кодека использовался "благословлённый" Apple код или нет. Я использовал исходный код ffdshow как документацию по формату, скорее всего ни одной точно совпадающей строчки между ним и libALAC вы не найдёте. Так же было и с libFlake. Когда код используется подобным образом, всё что от него требуется - это быть хорошо читаемым. Кем он написан, абсолютно неважно. Важно кем и как будет написан результирующий код по его мотивам.
Во вторых, варианты сжатия не меняют формат результирующего файла. В формате ALAC от фрейма к фрейму чередуются несколько методов кодирования стерео и количество коэффициэнтов предиктора. Выбирая степень сжатия энкодера, вы определяете только глубину перебора вариантов. По результирующему файлу нельзя точно сказать, какой алгоритм сжатия был использован. Иногда можно попытаться угадать по частоте встречаемости тех или иных фреймов. Частое использование фреймов с большим количеством коэффициэнтов предиктора может слегка влиять на скорость программной декомпрессии, но чипу ipod-а глубоко всё равно.
Ваше пожелание "не надо ничего делать" - наверное самое смешное пожелание, из тех что я получал от пользователей за очень долгое время. Боюсь, вынужден отказать. То, что вы называете фанатизмом, стремлением хакать, и судя по всему осуждаете, я называю желанием сделать лучше, и очень ценю в людях. Если бы не было этого желания, не было бы никакого прогресса, не было бы новых версий CUETools к примеру. Мы бы все сидели сложа руки и ждали подачек от компании Apple. Слушали бы музыку и копировали CD в iTunes, а не в foobar2000/EAC. Автору refAlac вы тоже пожелаете ничего не делать и ждать приложения от Apple? Я уж не говорю о том, что "ничего не делать" поздно - я написал libALAC за два года до появления refAlac. Я не могу вернуться назад во времени и сказать себе не делать этого  И не вижу смысла выкидывать libALAC сейчас только из-за того, что появился другой энкодер - который сжимает хуже, медленее, и не портирован на C#. А если бы я начал сейчас делать новый libALAC на основе кода от Apple, то в результате получился бы тот же самый код, который у меня получился три года назад.
И, да, я никогда не пользовался айподами и айфонами. И никогда не буду. Но это отдельный разговор 
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
14-Фев-12 02:46
(спустя 10 мин.)
gchudov писал(а):
Начнём с того, что код, который выложил Apple - это не тот код, который они используют сами. Это демонстрационный код, выложенный чтобы было понятно как устроен формат. В том виде, в котором они его выложили - он был достаточно медленным, неудобным к использованию и содержал ошибки. К пониманию структуры формата он ничего нового не добавил по сравнению с тем кодом, на котором я основывал libALAC.
Почему то все результаты кодирования QuickTime и Refalac сходятся, но не с LibALAC.
gchudov писал(а):
Так что между моей работой над libALAC и работой авторов refALAC нет никакой принципиальной разницы.
Разница в том, что у Refalac все результаты идентичные QuickTime, а у Вас нет.
gchudov писал(а):
Такое ощущение, что вы приписываете исходному коду некие мистические нематериальные свойства, типа "души" алгоритма, и для вас становится важно, при написании кодека использовался "благословлённый" Apple код или нет.
Для меня важно сохранение всех параметров кодирования родного кодека. Вижу Вас это не заботит, поэтому было предположение, что не пользуетесь яблочными девайсами нисколько. Собственно непонятно тогда зачем вообще ALAC разрабатывали?
gchudov писал(а):
Можно только пытаться угадывать по частоте встречаемости тех или иных фреймов. Это может слегка влиять на скорость программной декомпрессии, но чипу ipod-а глубоко всё равно.
Я давно не пользовался сторонними кодерами, но помнится проблем от их использования наглотался с лихвой. Ну а степень сжатия прежде всего влияет на работу самого плеера, хотя бы на время работы аккумулятора и т. д.
gchudov писал(а):
Ваше пожелание "не надо ничего делать" - наверное самое смешное пожелание, из тех что я получал от пользователей за очень долгое время.
Да пожелание было не на счет самогоо кодера, а на счет степеней сжатия. Хотите делать, никто не запретит. Может и яблочники оценят когда- нибудь.
Только не надо степень сжатия приписывать как безоговорочное преимущество вашего кодера.
gchudov писал(а):
То, что вы называете фанатизмом, стремлением хакать, и судя по всему осуждаете, я называю желанием сделать лучше, и очень ценю в людях. Если бы не было этого желания, не было бы никакого прогресса, не было бы новых версий CUETools к примеру. Мы бы все сидели сложа руки и ждали подачек от компании Apple. Слушали бы музыку и копировали CD в iTunes, а не в foobar2000/EAC.
Фанатизмом я называю не желание сделать лучше, а желание изменить то, что менять не надо.
На счет копирования скажу так. Мне лично пользоваться EAC просто интересно, ну и для трекера иногда надо. А вот чисто по сути мне по фигу чем скопировать музыку с CD.
gchudov писал(а):
И, да, я никогда не пользовался айподами и айфонами. И никогда не буду. Но это отдельный разговор
Ну так это как раз и проблема. Вы делаете формат для девайсов, которыми никогда не пользуетесь.
|
|
|
|
gchudov
Стаж: 16 лет 11 месяцев Сообщений: 138
|
gchudov ·
14-Фев-12 02:55
(спустя 9 мин.)
Что-то я устал отбиваться от какой-то бессмысленной критики на этом форуме. Только в русскоязычном интернете я сталкивался с тем, что людей ругают за полезную деятельность. Возьму ка тайм-аут и займусь лучше делом. А вы тут беседуйте, беседуйте
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
14-Фев-12 03:02
(спустя 7 мин.)
gchudov писал(а):
Что-то я устал отбиваться от какой-то бессмысленной критики на этом форуме. Только в русскоязычном интернете я сталкивался с тем, что людей ругают за полезную деятельность. Возьму ка тайм-аут и займусь лучше делом. А вы тут беседуйте, беседуйте
Да Вы не обижайтесь. Я не со зла. Хотелось тоже как лучше сделать.
Вообще началось все с того, что я просил Refalac включить в прогу по умолчанию. 
|
|
|
|
Fossman
Стаж: 18 лет 4 месяца Сообщений: 3570
|
Fossman ·
14-Фев-12 12:40
(спустя 9 часов, ред. 14-Фев-12 12:40)
gchudov писал(а):
В фубаре есть одна кнопка, и называется она "конвертировать". В настройках этой операции можно применять фильтры.
А на Солнце есть пятна. Только непонятно каким боком фильтры, если речь шли ИСКЛЮЧИТЕЛЬНО О КОНВЕРТИРОВАНИИ?! Или вам это невмоготу понять?
gchudov писал(а):
поэтому в теории на этой стадии возможны ошибки
Эта ваша "теория" в РАВНОЙ СТЕПЕНИ ОТНОСИТСЯ И К CUETOOLS. Так что опять мимо.
gchudov писал(а):
Единственная известная мне на текущий момент ошибка при конвертации в фубаре связана не с кодеками
Ну так опять же, речь идет О РАЗРЕЗАНИИ ФАЙЛА, А НЕ О КОНВЕРТИРОВАНИИ. У вас что-то сегодня затрудненное понимание элементарного и слов собеседников. Но поговорить очень хочется.
gchudov писал(а):
Нет. Я всего лишь указал вам на два неверных утверждения - что якобы оболочки не могут вносить ошибок и что якобы cuetools пользуется только стандартными кодеками.
Кодеков НАПИСАННЫХ ВАМИ В ПРОГРАММЕ CUETOOLS НЕТ. Вы это подтвердили (А если вы черенок позаимствованной лопаты обмотали изолентой это никак не дает вам право считать ее своей собственной). В чем неверность утверждений? Просто очень хочется черное белым назвать. Но тут не палата №6 смею вас заверить.
Насчет оболочек. Покажите мне пример фронтенда (или смоделируйте, чтобы результат можно было воспроизвести) работающего из командной строки со сторонними кодеками, который по вашим утверждениям, "вносит ошибки" в процесс КОНВЕРТИРОВАНИЯ (еще раз вам напомню, что речь шла о КОНВЕРТИРОВАНИИ - чтобы убедиться в этом медленно и вдумчиво прочитайте сообщения выше и не только свои). Очень сомневаюсь, что кроме пустых слов вы что-нибудь сможете и тут сказать по делу. Поэтому, априори, резюмирую, что и это ваше утверждение пальцем в небо.
gchudov писал(а):
Авторство, как почти всегда бывает в продуктах с открытым кодом, совместное.
Повторю, на всяки случай:
если вы черенок позаимствованной лопаты обмотали изолентой - это никак не дает вам право считать ее своей собственной.
И не нужно мне тут лабуду про ответственность (уголовную? финансовую? административную? гражданскую? юридическую?...). Ваша скромная задача сводится, как это очевидно, переложить готовый год на net и не наделать ошибок имени себя при этом. Вот и вся ответственность. Но автор алгоритма не вы. Вы приладили его к своему детищу (тоже позаимствованному в основе своей) и не более.
gchudov писал(а):
Вы уж конечно извините, господин Fossman, но у меня складывается ощущение что вы в этот топик зашли просто потроллить
Если бы вы, дорогой мой, читали более внимательно, то заметили, что вашей собственной оценке вы соответствуете в несоизмеримо большей степени. Кроме этого существует старинное правило, используемое недобросовестными людьми, которое можно выразить так:
"запихай в гавно другого и на его фоне будешь выглядеть лучше"
И заметьте - именно вы не въехали в суть разговора и непонятно зачем встряли, а когда сообразили, что наговорили кучу лажи, стали обвинять собеседника в нечистоплотности ведения дискуссии.
Что служит не только камнем в ваш огород, но и косвенным подтверждением правоты моих слов (для примера, i.simple, с которым у нас иногда бывают дискуссии - никогда не прибегал к подобным дешевым приемам, характерным для очень незрелых или недалеких людей).
P.S. До этого разговора с вами, я был более высокого мнения о вас.
А теперь я понимаю, почему элементарные баги вашего мода cuetools годами не исправляются.
|
|
|
|
Cornerstone
Стаж: 17 лет 8 месяцев Сообщений: 1583
|
Cornerstone ·
14-Фев-12 16:29
(спустя 3 часа, ред. 14-Фев-12 16:29)
Fossman
Fossman писал(а):
А теперь я понимаю, почему элементарные баги вашего мода cuetools годами не исправляются
"Что-бы не испортить впечатление о картине - никогда не знакомься с художником."
Fossman писал(а):
До этого разговора с вами, я был более высокого мнения о вас
Да. и вообще, gchudov очень экстравагантный чел - достаточно взглянуть About его программы при русскоязычном интерфейсе:
Цитата:
Пользуясь возможностью, хотел-бы попросить российских граждан требовать от своего правительства немедленного освобождения политических заключённых и вывода войск с аккупированных грузинских территорий. Григорий Чудов
А, вот при переходе на английский или немецкий интерфейс программы, он почему-то не обращается к американским и каким либо другим гражданам, что-бы они требовали от правительств своих стран аналогичных действий, например, по выводу войск из Афганистана или Ирака и т.д..... , так, что, чему Вы удивляетесь.
|
|
|
|
omegalord
Стаж: 18 лет 11 месяцев Сообщений: 1387
|
omegalord ·
14-Фев-12 17:14
(спустя 44 мин.)
Cornerstone писал(а):
Fossman Да. и вообще, gchudov очень экстравагантный чел - достаточно взглянуть About его программы при русскоязычном интерфейсе:
Цитата:
Пользуясь возможностью, хотел-бы попросить российских граждан требовать от своего правительства немедленного освобождения политических заключённых и вывода войск с аккупированных грузинских территорий. Григорий Чудов
А, вот при переходе на английский или немецкий интерфейс программы, он почему-то не обращается к американским и каким либо другим гражданам, что-бы они требовали от правительств своих стран аналогичных действий, например, по выводу войск из Афганистана или Ирака и т.д..... , так, что, чему Вы удивляетесь.
У светлых эльфов бомбы и пули демократичные. Понимать надо...
|
|
|
|
omavkome
Стаж: 20 лет 4 месяца Сообщений: 13212
|
omavkome ·
14-Фев-12 18:02
(спустя 48 мин.)
Читая Ваши комментарии, вспоминается сразу Василий Шукшин: "Срезал".
|
|
|
|
zicheslav
Стаж: 16 лет 4 месяца Сообщений: 2295
|
zicheslav ·
16-Фев-12 19:22
(спустя 2 дня 1 час)
А как в ней просто назначить папку выхода?
Чё-то всё как-то заморочено. В шаблоне какой-то .cue маячит, хотя я на треки хочу разрезать. .cue тут вообще причём? Открываю проводник, так там опять .cue-файл просит.
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
16-Фев-12 19:32
(спустя 9 мин.)
zicheslav писал(а):
А как в ней просто назначить папку выхода?
Чё-то всё как-то заморочено. В шаблоне какой-то .cue маячит, хотя я на треки хочу разрезать. .cue тут вообще причём? Открываю проводник, так там опять .cue-файл просит.
По первому скрину. Оставляешь только Artist - Album.cue, а на место всего что до этого подставляешь свой путь.
|
|
|
|
Songs0fFailure
Стаж: 16 лет 4 месяца Сообщений: 2896
|
Songs0fFailure ·
16-Фев-12 19:32
(спустя 9 сек.)
zicheslav писал(а):
я на треки хочу разрезать. .cue тут вообще причём?
cue нужен... чтобы разрезать на треки образ.
|
|
|
|
zicheslav
Стаж: 16 лет 4 месяца Сообщений: 2295
|
zicheslav ·
16-Фев-12 20:02
(спустя 30 мин., ред. 16-Фев-12 20:02)
Пытаюсь lossless-образ порезать на треки в mp3.
Лютая дичь, а не программа. Для простых и элементарных вещей.
Экьюрэйтрипы какие-то. На *** это нужно? Я чё раздачу собрался сотворять? Для таких дел EAC установил бы.
|
|
|
|
Songs0fFailure
Стаж: 16 лет 4 месяца Сообщений: 2896
|
Songs0fFailure ·
16-Фев-12 20:09
(спустя 7 мин.)
zicheslav писал(а):
Для таких дел EAC установил бы.
через xrecode II сделайте.
dll нужно закинуть. или лучше exe LAME с rarewares и свой пресет сделать с нужными параметрами кодирования.
По базе AR можно проверить на точность.
|
|
|
|
GeorgeGa
Стаж: 15 лет 5 месяцев Сообщений: 131
|
GeorgeGa ·
16-Фев-12 22:03
(спустя 1 час 53 мин., ред. 16-Фев-12 22:03)
zicheslav
Такое впечатление, что Вы не читаете хотя бы первые строчки из мануала. Прога в основном нужна для сохранения образа и для сравнения рипа по информации из базы данных.
Что- нибудь из перечисленного нужно для конвертации в МР3? Правильно, в МР3 можно порезать другими прогами, в частности XRecode II. Но потрудитесь почитать хоть немного из написанного в теме по XRecode II, иначе приобретете очередной геморрой на свою... и будете обвинять прогу во всех своих грехах.
zicheslav писал(а):
Экьюрэйтрипы какие-то. На *** это нужно? Я чё раздачу собрался сотворять? Для таких дел EAC установил бы.
Вы думаете EAC это конвертер? Судя по тому что написали, то да. Разочарую, EAC это рипер, а проблем с его настройкой если так же будете читать мануалы Вам прямо сказать гарантированны, и причем очень большие.
|
|
|
|
zicheslav
Стаж: 16 лет 4 месяца Сообщений: 2295
|
zicheslav ·
17-Фев-12 10:20
(спустя 12 часов)
Я в курсе, что EAC - это рипер. Сам пользовался несколько раз для создания раздач. Проблем с настройкой не возникло.
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
17-Фев-12 10:51
(спустя 31 мин., ред. 17-Фев-12 10:51)
zicheslav писал(а):
Проблем с настройкой не возникло.
Ну тогда и с CUETools не должно возникать, тем более, что для конвертации в МР3 в ней по умолчанию надо изменить только параметр обработки зазоров в положение Gaps Left Out, да и то не обязательно. Можно еще отключить получение информации из баз.
А в вашем случае элементарно не было энкодера (кодировщика) МР3 Lame_enc.dll, который не ставится в прогу по умолчанию по причине более частых обновлений чем сама прога. Его надо скачать в архиве LAME 3.99.4 и поместить в папку программы.
|
|
|
|
zicheslav
Стаж: 16 лет 4 месяца Сообщений: 2295
|
zicheslav ·
17-Фев-12 11:13
(спустя 21 мин.)
А куда и что именно вставить lame? Всю папку в папку cuetools? Или всю папку в папку plugins?
Я скачал lame, но в папке, помимо самой .dll, ещё куча файлов и пусковой файл .exe. Что именно и куда ставить?
|
|
|
|
megane68
Стаж: 17 лет 5 месяцев Сообщений: 19955
|
megane68 ·
17-Фев-12 11:24
(спустя 10 мин.)
zicheslav писал(а):
А куда и что именно вставить lame? Всю папку в папку cuetools? Или всю папку в папку plugins?
В корневую папку программы.
zicheslav писал(а):
Я скачал lame, но в папке, помимо самой .dll, ещё куча файлов и пусковой файл .exe. Что именно и куда ставить?
Один DLL только нужен. Lame.exe это альтернативный вариант энкодера командной строки, но в данном случае он не нужен, как и остальные файлы в архиве.
|
|
|
|
zicheslav
Стаж: 16 лет 4 месяца Сообщений: 2295
|
zicheslav ·
17-Фев-12 11:36
(спустя 12 мин.)
Значит я правильно сделал, до того как написал.
|
|
|
|
