Наконец-то исправили баг с треском, теперь не нужно держать параллельно фубар, всё играется отлично!
» AIMP (часть 2)
Цитата:
Наконец-то исправили баг с треском
это утверждение после ознакомления с чейнджлогом или после прослушивания нового релиза?
Цитата:
это утверждение после ознакомления с чейнджлогом или после прослушивания нового релиза?
После прослушивания. Теперь точно шумов нет.
bug_1: окно аимпа так и вылазит поверх всех (иногда)
bug_2: так и осталось некорректное отображение длительности треков/общей продолжительности/веса файла при проигрывании определённых cue+image
the_true_archa
1. локализировать баг не удается
2. по этому поводу все сказано, читайте ранее, правиться не будет (все сделано по спецификации CUE)
1. локализировать баг не удается
2. по этому поводу все сказано, читайте ранее, правиться не будет (все сделано по спецификации CUE)
В автозапуске AIMP забывает русский язык :)
AIMP 3.00 Build 985
Windows 7 64 bit
AIMP 3.00 Build 985
Windows 7 64 bit
Цитата:
все сделано по спецификации CUE
Я не знаю по какой спецификации и что сделано, но если я вижу, что в других программах данные параметры отображаются в каждой одинаково и правильно, это позволяет мне быть уверенным в том, что Аимп эти параметры отображает неправильно. Удивляет упрямость разработчика игнорировать сей факт и апеллировать к умным словам.
К тому же, в двух последних бетах при переходе с одного трека на другой Аимп заставляет систему виснуть на 7-8 секунд, и зависает сам (W7 SP1 x86 1Gb RAM)
Ligre, если переводить этот пункт, то при смене языка придется опять переассоциировать программу. (пересказ слов Артема)
the_true_archa
http://ru.wikipedia.org/wiki/Cue_sheet
http://rutracker.org/forum/viewtopic.php?t=1942027
http://wyday.com/cuesharp/specification.php
Если кто-то что-то делает - это не значит, что он делает это правильно. К тому же у Винампа поддержка КУЕ не нативная, а кто писал плагин - шиш его знает.
А теперь ответьте мне (нам):
Какие спецификации можете привести, где указано и разжевано, как надо делать? (выше я привел парочку объяснений по ссылкам и там четко написано, что отрывок между ИНДЕКС00 и ИНДЕКС01 играется с отрицательным временем).
П.С. Дайте ссылку на этот КУЕ (КУЕ+аудио), чтобы уж проверять/смотреть на нем.
the_true_archa
http://ru.wikipedia.org/wiki/Cue_sheet
http://rutracker.org/forum/viewtopic.php?t=1942027
http://wyday.com/cuesharp/specification.php
Если кто-то что-то делает - это не значит, что он делает это правильно. К тому же у Винампа поддержка КУЕ не нативная, а кто писал плагин - шиш его знает.
А теперь ответьте мне (нам):
Какие спецификации можете привести, где указано и разжевано, как надо делать? (выше я привел парочку объяснений по ссылкам и там четко написано, что отрывок между ИНДЕКС00 и ИНДЕКС01 играется с отрицательным временем).
П.С. Дайте ссылку на этот КУЕ (КУЕ+аудио), чтобы уж проверять/смотреть на нем.
Цитата:
отрывок между ИНДЕКС00 и ИНДЕКС01 играется с отрицательным временем
Совершенно верно, прегап и должен проигрываться с отрицательным таймером.
Но! Я говорю совершенно о другом. И Ваши ссылки это подтверждают:
ru.wiki - INDEX 01 указывает непосредственно на начало текущего трека
рутрекер - 7. Краткие поясненияINDEX 01 всегда обозначает начало трека, а INDEX 00 -- начало зазора
Баг же третьего аимпа заключается в том, что началом трека считается INDEX 00 вместо INDEX 01
Из-за этого в плеере отображается некорректная инфа о длительности и весе файла, т.е. "выкидываются" все зазоры как-будто эти зазоры не являются частью файла-образа.
Только что провёл эксперимент: закинул в плеер APE+CUE (куй с INDEX 00) в одну вкладку, в другую вкладку закинул только .APE без куя. Как результат - .APE без куя имеет имеет и больший вес и время.
Какое ещё доказательство Вам требуется? Такого быть не может и не должно, т.к. куй только размечает файл-образ, но никоим образом не влияет на его вес/время
Цитата:
Дайте ссылку на этот КУЕ (КУЕ+аудио), чтобы уж проверять/смотреть на нем.
Да любой, хоть сами напишите, это ни на что влияет, обычный текстовый файл с расширением cue
И чем больший промежуток между INDEX 00 и INDEX 01, тем меньшее время/вес будет отображаться в аимпе.
UPD: #
the_true_archa, Вы только что сами себе спротиворечили аж два раза (если так можно выразиться).
Цитата:
1. Вы сами прочитали и поняли, что начало трека считается от ИНДЕКС01, а ИНДЕКС00 дает отрицательный отсчет! В АИМП3 так и есть!
2. Соответственно этот "зазор" выбрасывается из расчета, т.к. не является треком. Отсюда меньше длина файла и меньше вес. (пример: 100с - 4 раза по 5с = 80с - длина меньше)
Пример из Вашего же файла http://forum.ru-board.com/topic.cgi?forum=5&topic=33078&start=1425&limit=1&m=1#1
TRACK 02 AUDIO
INDEX 00 06:50:45
INDEX 01 06:58:35
TRACK 03 AUDIO
INDEX 00 15:03:62
INDEX 01 15:11:52
TRACK 04 AUDIO
INDEX 00 16:56:10
INDEX 01 17:04:00
Трек 2 идет с 6:58:35 до 15:03:62, далее "зазор", который не является треком, соответственно не учитывается ни в длине, ни в весе (вес - производная длины трека), трек 3 идет с 15:11:52 до 16:56:10.
Добавлено:
Цитата:
Я знаю как делать КУЕ, но я попросил дать пример (мне еще делать нечего, как КУЕ сочинять). К тому же на мои факты (которые я не ленюсь искать и приводить) Вы не приводите никаких своих, только неправильно читаете матчасть и что-то пытаетесь доказать... Мне кажется это разговор с глухим...
Цитата:
Баг же третьего аимпа заключается в том, что началом трека считается INDEX 00 вместо INDEX 01
Из-за этого в плеере отображается некорректная инфа о длительности и весе файла, т.е. "выкидываются" все зазоры как-будто эти зазоры не являются частью файла-образа.
1. Вы сами прочитали и поняли, что начало трека считается от ИНДЕКС01, а ИНДЕКС00 дает отрицательный отсчет! В АИМП3 так и есть!
2. Соответственно этот "зазор" выбрасывается из расчета, т.к. не является треком. Отсюда меньше длина файла и меньше вес. (пример: 100с - 4 раза по 5с = 80с - длина меньше)
Пример из Вашего же файла http://forum.ru-board.com/topic.cgi?forum=5&topic=33078&start=1425&limit=1&m=1#1
TRACK 02 AUDIO
INDEX 00 06:50:45
INDEX 01 06:58:35
TRACK 03 AUDIO
INDEX 00 15:03:62
INDEX 01 15:11:52
TRACK 04 AUDIO
INDEX 00 16:56:10
INDEX 01 17:04:00
Трек 2 идет с 6:58:35 до 15:03:62, далее "зазор", который не является треком, соответственно не учитывается ни в длине, ни в весе (вес - производная длины трека), трек 3 идет с 15:11:52 до 16:56:10.
Добавлено:
Цитата:
Да любой, хоть сами напишите, это ни на что влияет, обычный текстовый файл с расширением cue
Я знаю как делать КУЕ, но я попросил дать пример (мне еще делать нечего, как КУЕ сочинять). К тому же на мои факты (которые я не ленюсь искать и приводить) Вы не приводите никаких своих, только неправильно читаете матчасть и что-то пытаетесь доказать... Мне кажется это разговор с глухим...
Народ, покажите пожалуйста скриншот с тем, как плеер отображает треклист с cue-файла, отдельным окошком или в списке воспроизведения, где находится сам сэт\альбом?
Цитата:
я попросил дать пример (мне еще делать нечего, как КУЕ сочинять)
Под ковриком же ссылка.
Цитата:
1. Вы сами прочитали и поняли, что начало трека считается от ИНДЕКС01, а ИНДЕКС00 дает отрицательный отсчет! В АИМП3 так и есть!
Разве я что-то говорил на сей счёт? Да, от индекса 00 до индекса 01 аимп ведёт отсчёт на минус, так и должно быть, всё нормально.
Цитата:
Соответственно этот "зазор" выбрасывается из расчета, т.к. не является треком
А это ещё почему? Почему зазор должен выбрасываться из расчёта? Где написано, что кусок от 00 до 01 не является треком? Где написано, что этот кусок выбрасывается? Он что, не существует? Даже если между 00 и 01 просто тишина, почему этот кусок должен выбрасываться и не браться в расчёт? Где об этом написано? Напротив, кусок от 00 до 01 прибавляется к предыдущему треку, но никуда не выбрасывается
Баг Аимпа3 в том, что переход на следующий трек происходит по индексу 00, тогда как концом текущего трека является индекс 01 следующего.
(железная цд-плита тоже совершенно корректно ведёт отрицательный отсчёт между 00 и 01, но началом и концом трека для неё является индекс 01)
[more=EAC-log]Exact Audio Copy V1.0 beta 3 from 29. August 2011
Отчёт EAC об извлечении, выполненном 24. мая 2012, 22:14
Abigor / Verwuјstung / Invoke The Dark Age
Дисковод: Optiarc DVD RW AD-7170A Adapter: 0 ID: 0
Режим чтения : Достоверность
Использование точного потока : Да
Отключение кэша аудио : Да
Использование указателей C2 : Нет
Коррекция смещения при чтении : 48
Способность читать области Lead-in и Lead-out : Нет
Заполнение пропущенных сэмплов тишиной : Да
Удаление блоков с тишиной в начале и конце : Нет
При вычислениях CRC использовались нулевые сэмплы : Да
Интерфейс : Встроенный Win32-интерфейс для Win NT/2000
Выходной формат : Внутренние WAV-операции
Формат сэмплов : 44.100 Гц; 16 бит; стерео
TOC извлечённого CD
Трек | Старт | Длительность | Начальный сектор | Конечный сектор
---------------------------------------------------------------------
1 | 0:00.00 | 6:58.35 | 0 | 31384
2 | 6:58.35 | 8:13.17 | 31385 | 68376
3 | 15:11.52 | 1:52.23 | 68377 | 76799
4 | 17:04.00 | 5:24.10 | 76800 | 101109
5 | 22:28.10 | 4:20.05 | 101110 | 120614
6 | 26:48.15 | 5:50.65 | 120615 | 146929
7 | 32:39.05 | 4:45.50 | 146930 | 168354
8 | 37:24.55 | 3:00.62 | 168355 | 181916
9 | 40:25.42 | 2:03.55 | 181917 | 191196
Характеристики диапазона извлечения и сообщения об ошибках
Выбранный диапазон
Имя файла C:\-=MUSIC=-\Abigor - Verwuјstung , Invoke The Dark Age.wav
Пиковый уровень 100.0 %
Скорость извлечения 33.8 X
Качество диапазона 100.0 %
CRC теста D6ECA8DE
CRC копии D6ECA8DE
Копирование... OK
Ошибок не произошло
AccurateRip: сводка
Трек 1 : извлечено точно (доверие 2) [D0B8856E] (AR v1)
Трек 2 : извлечено точно (доверие 2) [284248C9] (AR v1)
Трек 3 : извлечено точно (доверие 2) [449B9D53] (AR v1)
Трек 4 : извлечено точно (доверие 2) [212E509D] (AR v1)
Трек 5 : извлечено точно (доверие 2) [2B376A56] (AR v1)
Трек 6 : извлечено точно (доверие 2) [583F6668] (AR v1)
Трек 7 : извлечено точно (доверие 2) [7C3CC5FA] (AR v1)
Трек 8 : извлечено точно (доверие 2) [891E3EA6] (AR v1)
Трек 9 : извлечено точно (доверие 2) [38721776] (AR v1)
Все треки извлечены точно
Конец отчёта
[/more] + [more=Cue]REM GENRE "Black Metal"
REM DATE 1994
REM DISCID 5D09F509
REM COMMENT "ExactAudioCopy v1.0b3"
PERFORMER "Abigor"
TITLE "Verwuјstung / Invoke The Dark Age"
FILE "Abigor - Verwuјstung , Invoke The Dark Age.wav" WAVE
TRACK 01 AUDIO
TITLE "Universe Of Black Divine"
PERFORMER "Abigor"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Kingdom Of Darkness"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 06:50:45
INDEX 01 06:58:35
TRACK 03 AUDIO
TITLE "Beneath A Steel Sky"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 15:03:62
INDEX 01 15:11:52
TRACK 04 AUDIO
TITLE "Eye To Eye At Armageddon"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 16:56:10
INDEX 01 17:04:00
TRACK 05 AUDIO
TITLE "In Sin"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 22:20:20
INDEX 01 22:28:10
TRACK 06 AUDIO
TITLE "My Soft Vision In Blood"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 26:40:25
INDEX 01 26:48:15
TRACK 07 AUDIO
TITLE "Weeping Midwintertears"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 32:31:15
INDEX 01 32:39:05
TRACK 08 AUDIO
TITLE "Diabolic Unity"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 37:16:65
INDEX 01 37:24:55
TRACK 09 AUDIO
TITLE "A Spell Of Dark And Evil"
PERFORMER "Abigor"
FLAGS DCP
INDEX 00 40:17:52
INDEX 01 40:25:42
[/more]
EAC - программа-эталон точности снятия образа диска. Началом трека является индекс 01, концом трека - также индекс 01 (следующего трека), и ЕАС это наглядно показывает.
------------
UPD:
Индекс 01 всегда имеет приоритет над индексом 00. За разбиение образа на треки отвечает именно индекс 01, именно по индексу 01 происходит окончание (или начало) треков. Удалив из куя индексы 00 не произойдёт ровно ничего, ни один фрейм не потеряется и не "выбросится", просто таймер будет отсчитывать каждый трек в одном режиме (я не говорю про те случаи, когда диск имеет скрытый прегап перед первым треком или индексы 01-99, но это специальные случаи).
Время трека отсчитывается от индекса 01 текущего, и до индекса 01 следующего трека. Но никак не до 00!
00-01 это всего лишь зазор между треками, и добавляется он к предыдущему треку, но никуда не выбрасывается.
the_true_archa
Цитата:
Тем более что там отнюдь не всегда тишина.
Цитата:
Даже если между 00 и 01 просто тишина
Тем более что там отнюдь не всегда тишина.
[more] Всем привет.
Попробую объяснить, почему именно такое поведение было выбрано для AIMP3.
Между индексами 00 и 01 обычно заключают одну из двух вещей: паузу между треками (т.е. просто тишину), и кроссмикс одного трека в другой. Согласитесь, что ни одно, ни другое нельзя с уверенностью отнести к одному из треков - это что-то среднее между ними.
Здесь предлагалось следующее решение - относить гап к предыдущему треку, это не совсем верно:
1) Почему мы должны приплюсовывать тишину к предыдущему треку, если по задумке автора у этого трека тишины в конце быть не должно?
2) Почему часть следующего трека должна звучать в рамках предыдущего трека? Представьте, что мы проигрываем сэт НЕ по порядку, в данном случае получится такая вот какофония: трек заканчивается и плавно перетекает в следующий (играется "гап"-часть), затем плеер так же плавно миксует эту часть с совершенно другим треком, в итоге в переходе с трека на трек участвуют три разных трека! Вы считаете это правильным?
Я не могу сказать, почему другие программы используют более простой подход, но я считаю, что так делать нельзя. Если гап обозначен в CUE, значит он там реально нужен. Если бы на гап можно было забить - в CUE он бы отсутствовал.
Почему гап не участвует в расчете длительности? В принципе, это вытекает из рассуждений выше: гап - не имеет отношения ни к одному из треков, это своего рода эффект перехода с одного трека на другой. Плейлист же, в свою очередь, показывает время и размер виртуальных треков, а не образа в целом. Стоит так же отметить, что образ может содержать дополнительные файлы - обложки альбомов, спектры и т.п. [/more]
Попробую объяснить, почему именно такое поведение было выбрано для AIMP3.
Между индексами 00 и 01 обычно заключают одну из двух вещей: паузу между треками (т.е. просто тишину), и кроссмикс одного трека в другой. Согласитесь, что ни одно, ни другое нельзя с уверенностью отнести к одному из треков - это что-то среднее между ними.
Здесь предлагалось следующее решение - относить гап к предыдущему треку, это не совсем верно:
1) Почему мы должны приплюсовывать тишину к предыдущему треку, если по задумке автора у этого трека тишины в конце быть не должно?
2) Почему часть следующего трека должна звучать в рамках предыдущего трека? Представьте, что мы проигрываем сэт НЕ по порядку, в данном случае получится такая вот какофония: трек заканчивается и плавно перетекает в следующий (играется "гап"-часть), затем плеер так же плавно миксует эту часть с совершенно другим треком, в итоге в переходе с трека на трек участвуют три разных трека! Вы считаете это правильным?
Я не могу сказать, почему другие программы используют более простой подход, но я считаю, что так делать нельзя. Если гап обозначен в CUE, значит он там реально нужен. Если бы на гап можно было забить - в CUE он бы отсутствовал.
Почему гап не участвует в расчете длительности? В принципе, это вытекает из рассуждений выше: гап - не имеет отношения ни к одному из треков, это своего рода эффект перехода с одного трека на другой. Плейлист же, в свою очередь, показывает время и размер виртуальных треков, а не образа в целом. Стоит так же отметить, что образ может содержать дополнительные файлы - обложки альбомов, спектры и т.п. [/more]
ArtemIzmaylov, убедительно растолковано
Растолковано. Далеко не убедительно.
Ещё раз: EAC делит на треки ориентируясь исключительно на 01, фубар (а он специально заточен под лося) - также делит образ по индексу 01. Обе программы - исключительно эталонны в области lossless. Да, может это, как выразился Артём, "более простой подход". Но именно этот подход демонстрируют и все мои цд-плиты. Значит такой подход является стандартом.
FLAC+CUE (+log) - это цельный образ аудио-сд. И читаться и воспроизводиться он должен именно, как цельный образ, без "выбрасываний" или нечитания гапов. На то он и образ - как матрица с диска.
ArtemIzmaylov
Цитата:
Вот и я спрашиваю, почему? Почему в ЕАСе и фубаре гап участвует, а в 3-ем Аимпе - нет?
Ещё раз: EAC делит на треки ориентируясь исключительно на 01, фубар (а он специально заточен под лося) - также делит образ по индексу 01. Обе программы - исключительно эталонны в области lossless. Да, может это, как выразился Артём, "более простой подход". Но именно этот подход демонстрируют и все мои цд-плиты. Значит такой подход является стандартом.
FLAC+CUE (+log) - это цельный образ аудио-сд. И читаться и воспроизводиться он должен именно, как цельный образ, без "выбрасываний" или нечитания гапов. На то он и образ - как матрица с диска.
ArtemIzmaylov
Цитата:
Почему гап не участвует в расчете длительности?
Вот и я спрашиваю, почему? Почему в ЕАСе и фубаре гап участвует, а в 3-ем Аимпе - нет?
Цитата:
Да, может это, как выразился Артём, "более простой подход". Но именно этот подход демонстрируют и все мои цд-плиты. Значит такой подход является стандартом.
Ничего себе, вот бы мне так рассуждать! К сожалению, вы не привели ни одного контраргумента, за исключением не внятной фразы "все так делают, значит и вы должны". К сожалению, с таким подходом у нас с вами конструктивного общения не получится.
Цитата:
FLAC+CUE (+log) - это цельный образ аудио-сд. И читаться и воспроизводиться он должен именно, как цельный образ, без "выбрасываний" или нечитания гапов. На то он и образ - как матрица с диска.
В таком случае убирайте CUE файл - плеер будет жевать его как единое целое.
Цитата:
Вот и я спрашиваю, почему? Почему в ЕАСе и фубаре гап участвует, а в 3-ем Аимпе - нет?
Я уже ответил на этот вопрос в своем предыдущем посте
Цитата:
за исключением не внятной фразы "все так делают, значит и вы должны"
Молодой человек, право, не стоит приписывать мне то, что я не говорил.
Я ссылаюсь на программы-эталоны (ЕАС и фубар), а также на железные плиты. Из этого я делаю вывод (есть доказательства против этого?), что это является стандартом. Если для Вас это является "не внятной фразой", то.. слов нет.
Цитата:
В таком случае убирайте CUE файл - плеер будет жевать его как единое целое.
Браво! Настоящий ответ "компетентного" человека. Выкинь половину и получишь целое.
Что интересно, в данном ответе автор признаёт неспособность программы (правильно) читать Cue. Несмотря на то, что cue является файлом образа.
[more] Я считаю, что поведение в AIMP3 в рамках _воспроизведения_ более правильное, нежели в приведенных вами программах. Аргументы я привел. То, что фубар существуют на рынке дольше нас, не делает его поведение стандартом. EAC вообще отдельная тема для разговора - это не плеер. Было бы странным, согласитесь, если бы Nero при рипе или записи образа что-нибудь оттуда выкидывал?
Цитата:
Во-первых, CUE - является не файлом образа, а всего лишь его разметкой. Если говорить про аудио-"образы", то они ничем не отличаются от обычного аудио файла. В данном случае разметка позволяет лишь удобно перемещаться по композициям, скорее даже частям, одного большого файла.
Во-вторых, я дал вам всего лишь решение.
И очень бы хотелось мне знать, в чем именно мои выводы ложны? Для чего, на ваш взгляд, нужны гапы в файлах разметки? Пожалуйста, не нужно ссылаться на программы-"эталоны", это не аргумент.
[/more]
Цитата:
Браво! Настоящий ответ "компетентного" человека. Выкинь половину и получишь целое.
Что интересно, в данном ответе автор признаёт неспособность программы (правильно) читать Cue. Несмотря на то, что cue является файлом образа.
Во-первых, CUE - является не файлом образа, а всего лишь его разметкой. Если говорить про аудио-"образы", то они ничем не отличаются от обычного аудио файла. В данном случае разметка позволяет лишь удобно перемещаться по композициям, скорее даже частям, одного большого файла.
Во-вторых, я дал вам всего лишь решение.
И очень бы хотелось мне знать, в чем именно мои выводы ложны? Для чего, на ваш взгляд, нужны гапы в файлах разметки? Пожалуйста, не нужно ссылаться на программы-"эталоны", это не аргумент.
[/more]
the_true_archa
Цитата:
Где аргументы, что это именно так? Почему из полутора десятков плееров, поддерживающих CUE, выбраны именно эти (EAC и не плеер даже), тогда уж стоило посмотреть на CDRWIN, откуда вообще это началось. Или XMPlay и WinAmp (автор fb2k из Nullsoft-а вышел)?
P. S. Длительность записи - весь альбом или сумма длительности треков - тут вопрос неоднозначный. Есть альбомы, которые концептуально даже нельзя разбить на треки. Хотя частенько это делают и куски выдаются за отдельные самостоятельные треки. Но, IMHO, чаще встречаются альбомы - наборы отдельных самодостаточных произведений.
P. P. S. А по сути спора, IMHO, the_true_archa прав. У меня из 12 плееров (некоторые не понимают CUE, но воспроизводят lossless), только AIMP3 показал своё время, остальные 11 - одинаково. В том числе и AIMP2! А так же в их числе WinAmp и XMPLay.
Цитата:
программы-эталоны (ЕАС и фубар)
Где аргументы, что это именно так? Почему из полутора десятков плееров, поддерживающих CUE, выбраны именно эти (EAC и не плеер даже), тогда уж стоило посмотреть на CDRWIN, откуда вообще это началось. Или XMPlay и WinAmp (автор fb2k из Nullsoft-а вышел)?
P. S. Длительность записи - весь альбом или сумма длительности треков - тут вопрос неоднозначный. Есть альбомы, которые концептуально даже нельзя разбить на треки. Хотя частенько это делают и куски выдаются за отдельные самостоятельные треки. Но, IMHO, чаще встречаются альбомы - наборы отдельных самодостаточных произведений.
P. P. S. А по сути спора, IMHO, the_true_archa прав. У меня из 12 плееров (некоторые не понимают CUE, но воспроизводят lossless), только AIMP3 показал своё время, остальные 11 - одинаково. В том числе и AIMP2! А так же в их числе WinAmp и XMPLay.
Цитата:
А по сути спора, IMHO, the_true_archa прав. У меня из 12 плееров (некоторые не понимают CUE, но воспроизводят lossless), только AIMP3 показал своё время, остальные 11 - одинаково. В том числе и AIMP2! А так же в их числе WinAmp и XMPLay.
Я пояснил, почему время в AIMP3 отличается, он не причитает длительность пауз / переходов к каким-либо трекам.
У меня нет ни времени ни желания витийствовать по поводу спецификаций и что для чего нужно.
Цитата:
Я как раз именно буду ссылаться на эталон, т.к. эталон - это стандарт.
Я не пришёл сюда выражать какое-то своё мнение, я показываю, что есть стандарт.
А по эталону - да, ЕАС - эталон, и правильность его лога - также эталон, принятый в мире лосслесс (верный оффсет для дисковода, режим Secure, отключенный кэш, плюс в последнее время практически обязательный режим тест-н-копи). ТОС лога ЕАС - также является единственно верным (при условии правильности снятия образа). Также эталоном является CUETools, создаваемый им ТОС идентичен ТОСу у ЕАС. Это не плееры, но разговор не об этом, а об индексах куя, о ТОСе. Так вот, если эти две проги дают совершенно конкретный ТОС, то этот все данные этого ТОСа являются единственно верными, то есть СТАНДАРТОМ. Это не какое-то моё личное мнение, это стандарт, принятый как на НетЛабе, так и на Вате, Вафлях, ММТ и рутрекере.
И, как видно, основные плееры также придерживаются этого стандарта.
Да и как-то нелепо это: один и тот же диск, рипнутый образом + куй, показывает совершенно разное время треков нежели тот же самый диск, зарипанный потреково без куя.
Если уж очень хочется, чтоб была эта фича - время на минус при проигрывании гапов (кстати, действительно классная и нужная фича), так не в ущерб же ТОСу.
Цитата:
Пожалуйста, не нужно ссылаться на программы-"эталоны", это не аргумент.
Я как раз именно буду ссылаться на эталон, т.к. эталон - это стандарт.
Я не пришёл сюда выражать какое-то своё мнение, я показываю, что есть стандарт.
А по эталону - да, ЕАС - эталон, и правильность его лога - также эталон, принятый в мире лосслесс (верный оффсет для дисковода, режим Secure, отключенный кэш, плюс в последнее время практически обязательный режим тест-н-копи). ТОС лога ЕАС - также является единственно верным (при условии правильности снятия образа). Также эталоном является CUETools, создаваемый им ТОС идентичен ТОСу у ЕАС. Это не плееры, но разговор не об этом, а об индексах куя, о ТОСе. Так вот, если эти две проги дают совершенно конкретный ТОС, то этот все данные этого ТОСа являются единственно верными, то есть СТАНДАРТОМ. Это не какое-то моё личное мнение, это стандарт, принятый как на НетЛабе, так и на Вате, Вафлях, ММТ и рутрекере.
И, как видно, основные плееры также придерживаются этого стандарта.
Да и как-то нелепо это: один и тот же диск, рипнутый образом + куй, показывает совершенно разное время треков нежели тот же самый диск, зарипанный потреково без куя.
Если уж очень хочется, чтоб была эта фича - время на минус при проигрывании гапов (кстати, действительно классная и нужная фича), так не в ущерб же ТОСу.
ОК!
Только что попробовал последний Аимп 3 и заметил что рекордера для Аимпа 3 нет. Можно ли как-то присобачить рекордер от второй версии?
Еще заметил что вроде звук стал лутчше чем в ранних третих версиях, кто-нибудь может это подтвердить? До этого использовал Аимп 2 с IN_MAD плагином, а без него ни как.
Еще заметил что вроде звук стал лутчше чем в ранних третих версиях, кто-нибудь может это подтвердить? До этого использовал Аимп 2 с IN_MAD плагином, а без него ни как.
Намного лучше. Особенно, если включить DirectSound 192/32. Правда, 192/32 проц здорово грузит
Цитата:
Намного лучше.
Не заметил. Правда, ухи не калиброванные. Разработчики анонсируют "собственную систему вывода звука, однако BASS используется как декодер." Тут я не понял - в AIMP используют какие-то алгоритмы "улучшайзинга" после декодировния?
Цитата:
если включить DirectSound 192/32
Позвольте усомниться, коллега. 44100/32 - это CD-качество, да? А если при прослушивании поднять частоту дискретизации до 192000, то рипанный-пережатый звук будет звучать лучше оригинала?
svobodny, есть в планах поддержка формата Shorten?
Chauvinist, а что это такое? Мы что-то не в курсах.
Хм, ну а плагин с офф сайта (http://www.etree.org/shnamp.html) не пашет?
svobodny
Цитата:
Пашет, спасибо.
Цитата:
Хм, ну а плагин с офф сайта (http://www.etree.org/shnamp.html) не пашет?
Пашет, спасибо.
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236
Предыдущая тема: Maxthon 2.x
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.