CUETools: Обзор программы (обсуждение) - 2

simple.i
Тут, судя по тому как он считает, не только арифметическая, но и ошибка в кол-ве фреймов которое захватывает отрезок, замечу именно отрезок, потому как дефис говорит о том, что это происходит на протяжении всего 43-го фрейма до 44-го, но никак не в них обоих. Если это происходит в двух фреймах, то запись должна быть, для данного случая, приблизительно, такой

Дефис действительно говорит о том, что ошибки находятся в отрезке. От фрейма 02:09:43 до фрейма 02:09:44 включительно. Если бы был задет только один фрейм, то не было бы никакого дефиса и был бы указан только один фрейм.
В одном фрейме действительно 588*2 сэмплов, поскольку сэмплами тут называется одно измерение одного канала, т.е. 16 бит.

gchudov Ну нигде и никогда такое написание не было включительным для ограничивающего справа значения И это просто чудесно, Вы действуете по принципу, если революцию сделаю не я, то кто-же ?
Все величины которыми мы оперируем временные и по вашему, временной отрезок увеличивается вдвое так как 1 фрейм это 1/75 секунды которая равна 588 сэмплам и в таком случае, по вышей формуле 1фрейм= 1/75 + 1/75 секунды.

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

омг. 0_o

Это общепринятое понятие сэмпла. Слышали о понятии bits per sample? Для CD-audio bits per sample = 16. Один сэмпл = 16 бит. В одном фрейме 588 сэмплов для каждого канала.

А я китайский диверсант.
Сэмпл - не сединица размера, а единица времени, равнач секунде делённой на частоту дискретизации. И количество сэмплов в секунде от количества каналов не зависит. А следуя Вашей логике, при частоте дискретизации (сэмплирования) 44100 Гц, в 1 секунде CD не 44100 сэмплов, а 88200, потому, что 2 канала. А если бы было не 2 канала, а 6, то в 1 секунде было бы 264600 семплов?
Вы бы хоть зашли в любой аудиоредактор, перевели временную шкалу во фреймы, выделили 1 фрейм, затем перевели в сэмплы и посмотрели, сколько их (сэмплов) во фрейме. Или посмотрели бы, чему равен 1 сэмпл в программах, с которыми CT взаимодействует. И в ЕАС 1 сэмпл = 4 байта, и в AR тоже (кстати, именно потому, что 2 канала), и в различных редакторах также и в тестирующих программах. Только у Вас 1 сэмпл = 2 байта, и сэмплов во фрейме не 588, а 1176.

http://en.wikipedia.org/wiki/Red_Book_(CD_standard)
The audio bit rate is 1,411.2 kbit/s (as 2 channels × 44,100 samples per second per channel × 16 bits per sample = 1,411,200 bit/s = 1,411.2 kbit/s). As each sample is a signed 16-bit two's complement integer, sample values range from −32768 to +32767.
Частота дискретизации - это количество сэмплов в секунду на канал.
Сэмпл всегда и везде это одно число, одно измерение значения сигнала, в случае CD - 16-битное. Это его формальное научное определение, оно же используется во всех стандартах, включая Red Book - стандарт, описывающий компакт диск.
Аудиоредакторы еще иногда используют то же самое слово как единицу измерения времени, равную интервалу времени между соседними сэмплами, но я никогда не слышал чтобы сэмпл использовали для обозначения например 4 байт информации в случае CD Audio. Если мы меряем информацию, то сэмпл это два байта. Если мы меряем время, то сэмпл это 1/44100 секунды.

http://en.wikipedia.org/wiki/Compact_Disc

gchudov
Вы приведите пример хотя бы одной программы, работающей с CD, в которой бы во фрейме было не 588, а 1176 сэмплов. Это ведь "общепринятое понятие", только никто, кроме Вас, его принимать не хочет. Только на CD 2 канала. Потому 16Х2 = 32. 1 сэмпл = 4 байта. Так принято у всех, кроме Вас.

Во фрейме 588 сэмплов. На канал. Итого 1176.
Так принято в науке и в стандартах. Вы можете считать как вам нравится

ИМХО, критики могли бы быть и повежливее, ведь, во-первых - альтернативы (по функционалу и удобству) - не существует, во-вторых - программа распространяется как freeware и развивается и совершенствуется лишь благодаря энтузиазму автора.

Об чём спор-то? Есть принципиальная разница, что считать семплом? +100500.

Л. М. Гога omegalord Из выше сказанного - получается, если Вам впаривают туфту смысл которой сводится к и при этом, единственным ей подтверждением на практике является голословное утверждение но бесплатно и безальтернативно, то люди которые с этим не согласны и никогда не встречали подтверждения таких выкладок на практике, и задающие вопрос: на который у автора этих утверждений ответа нет и быть не может, кроме им написанной программы, - поступают некорректно и их поведение, ни что иное, как невежливое отношение к автору этих утверждений. А, вот, если, это всё происходило-бы на альтернативной, и платной основе, то претензий к ним, я так понимаю, не было-бы. Браво!

А вот в этом Вы, уважаемый, не правы. Открываем документ под названием IEC 60908.1999 (ed2.0) на странице 15 и читаем Надеюсь с Red Book Вы спорить не будете?
Открываем программы, работающие с CD. ЕАС, dbpoweramp - изменение смещения на 1 сэмпл приводит к временнОму сдвигу потока на 4 байта, а не на 2. Открываем тестирующую программу Nero CD-DVD Speed, расширенный тест DAE. Смещение привода в ней представляется в 2-х единицах измерения - сэмплах и байтах, и 1 сэмпл при этом равен 4-м байтам. Берём программы коррекции для смещения WAVTools и (как ни странно, учитывая убеждения автора) CUETools - изменение смещения рипа на 1 сэмпл приводит к сдвигу на 4 байта. И 1 сэмпл во всех этих программах равен 1 сэмплу по временнОй шкале в любом аудиоредакторе, если открыть в нём звуковой файл в формате 44100/16 стерео. И если посчитать количество сэмплов на фрейм в аудиоредакторе, то их будет 588, а не 1176. И если удалить 1 сэмпл в аудиоредакторе, то аудиофайл станет короче на 4 байта, а не на 2. И как бы Вы того не хотели, но удалить половину сэмпла (только 1 канал) Вам не удастся, как не удастся загрузить файл, если в нём не будет хватать 2-х байт, без возникновения ошибки non integer value. Потому, что в 1 сэмпле, для этого формата, должны присутствовать оба канала, как и сказано в стандарте Red Book, цитату из которого я привёл выше.
И частота дискретизации не изменяется с увеличением числа каналов. 44100/16 стерео и 44100/16 моно имеют одну и ту же частоту дискретизации (сэмплирования) - 44100 Гц. Это частота генератора тактирующих импульсов для АЦП при оцифровке сигнала.

Альтернативы для весьма и весьма скромного функционала программы? Это вы малость не того съели наверное, если так думаете... Про "удобство" вообще умолчу... Ну вообще-то, это не самостоятельная программа, а мод программы. Автор оригинальной программы другой (и если бы не он, то и данного мода (на который вы молитесь), думаю, не существовало бы):
http://moitah.net/

С чем вы предлагаете спорить? С тем что сэмплы берутся парами? Не буду спорить. Полноты картины для, приведу продолжение вашей цитаты. Следующая же строка говорит, что сэмплы - 16-битные. А не 32. Естественно. Потому что на 1 сэмпл сдвигаются оба канала одновременно. Кто ж с этим спорит.
А вот попробуйте в EAC включить опцию "No use of null samples for CRC calculations" и проанализируйте результаты. И вы с удивлением для себя обнаружите, что EAC будет игнорировать не нулевые 4-х байтные блоки, а нулевые сэмплы - т.е. 2-х байтные блоки. Попробуйте доказать Andre, что он неправ
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92896&view=findpost&p=782576 Ну и конечно Peter Pawlowski тоже неправ, foobar2000 почему-то тоже считает сэмплами 16-битные числа: http://www.hydrogenaudio.org/forums//lofiversion/index.php/t73112.html Так никто и не спорит. 588 сэмплов. На каждый канал. А вот тут вы не правы. В 1 сэмпле согласно Red Book должны присутствовать 16 бит. Но конечно, сэмплы должны присутствовать всегда парами. По одному на канал. Дык кто спорит то.
Какой-то спор тупоконечников с остроконечниками.
Можно говорить что в секторе 588 пар сэмплов, а можно говорить что в секторе 588 сэмплов, если сэмплами называть пары чисел. Но в стандартах, и в науке (теории обработки сигналов) используется первый вариант, т.е. sample = один замер одного сигнала, т.е. число. Для второго понятия обычно придумывают другой термин, например stereo sample или inter-channel sample.
Вот например описание формата .wav: http://www-mmsp.ece.mcgill.ca/documents/audioformats/wave/Docs/riffmci.pdf Перевожу: поле wBitsPerSample указывает количество битов информации, используемых для представления одного сэмпла каждого канала. При наличии нескольких каналов, размер сэмплов одинаков для всех каналов. В мультиканальных WAVE файлах сэмплы разных каналов чередуются.
Вот описание формата flac: http://flac.sourceforge.net/format.html http://dranger.com/ffmpeg/tutorial03.html http://www.digitizationguidelines.gov/term.php?term=interleavedsampleaudio Я уже всеми возможными способами попытался объяснить. Больше не хочу тратить на это своё время. Тему для себя считаю закрытой.

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

gchudov
https://rutr.life/forum/viewtopic.php?p=49573104#49573104
и ниже. хм..
http://www.herongyang.com/CD-DVD/Audio-CD-Data-Structure.html
frame=588 бит зы.
6 сэмплов во фрэйме *98 фрэймов =588 сэмплов в секторе для двух каналов.
похоже где-то кто-то попутал
сектор = 588 samples
и
frame(кадр же?)=588 bits
Нэ ? 6 сэмлов во фрэйме. 0_o
я запутался.

Я еще не разбирался подробно. Насколько я помню, EAC иногда пишет гапы в сотых долях секунды, иногда во фреймах. Мне тогда показалось что в 99% случаев в сотых долях секунды, и я тогда поленился разбираться, как отличить, когда во фреймах. Если кто знает, например, в каких версиях EAC была такая настройка, поделитесь.

Вот ещё ошибочная цитата One frame = One sector.
gchudov
хех. а если на CUE полагаться ? там то всегда ээ... то что нужно короче.
или сравнивать pregap в cue и log.
о. вот ещё.
75 sectors per second. т.е 588*75=44100 сэмлов в секунду.
но! в cue! блдж!
вот как фрэймы и секторы перепутались ? типа для удобства на пк секторы стали именовать фрэймами ?

Типа да... Фреймами вообще что только не называют.

ОК! Закрыта. Действительно спор почти ни о чём.
Но, всё же, считаю, что и в данном случае лучше было бы считать сэмплы парные, для удобства понимания пользователей, дабы не углубляться в дебри толкований, ведь данная строка лишь аналитическая и служит для оценкий размера повреждённой области. От этого увольте. Доказать Андрэ, что он неправ - задача почти неразрешимая, даже если его неправота очевидна. Во всех версиях. Как представлять доли секунды - в милисекундах или во фреймах - зависит от настроек пользователя (включит или нет галку показа во фреймах). Примерно в половине случаев отличить, в каких единицах представлены доли секунды, невозможно. Определить можно только по исключениям, если попадаются значения, которых во фреймах или в милисекундах быть не может, или по размеру предзазора первого трека, если он длинее 2-х секунд. Да тут всё просто. 1/75 доля секунды - фрейм, который физически равен 1-му сектору на диске. В нём 98 микрокадров (small frame) - минимальных блоков информации на диске - по 24 байта информации в каждом. 24 байта = 6 сэмплов. 6Х98=588 сэмплов во фрейме или секторе.
Ну и так уж случилось, что в 1-м микрокадре (small frame) 588 бит. 24 бита синхронизации; байт субкода + 24 байта данных + 8 байт восстановления (коды Рида=Соломона) = 33 байта, после применения канальной модуляции 8/14 = 462 бита; и 34 блока по 3 бита соединения = 102 бита. Итого 24+462+102=588.

Какие "архиважные и незаменимые" функции, имеющиеся в cuetools вас интересуют (то есть, их ни в одной программе нет по-вашему, но они крайне важны для пользователей), чтобы предметно говорить о том, что вам неизвестно?
(Спрашиваю неспроста, поскольку мне таковые неизвестны, а, вот например, в foobar2000 (поклонником коего не являюсь) могу назвать парочку таковых, найти альтернативу которым среди других программ действительно непросто)

Для меня одной из самых существенных (полезных в сортировке lossless коллекции) является Local Database с функцией поиска двойников. Ничего подобного в других программах я не видел. Конечно, хотелось бы более богатый функционал, но и то что есть - весьма помогает в сортировке. Пожалуй самая острая необходимость - это возможность открытия из cuetools папки рипа в проводнике а так же одновременного открытия всех папок (для группы предполагаемых или подтвержденных двойников).
Так же, очень часто пользуюсь проверкой по базе и конвертацией. Еще функция repair пару раз мне пригодилась. Опять же теги, или, скажем, ситуации, когда в cue не прописаны названия композиций...
Вот, примерно такой список - все в одной программе, необходимости использовать какие то другие продукты у меня, практически, не возникает. Некоторыми функциями фубара - тоже пользуюсь иногда, но относительно редко...а какие именно там уникальные функции есть? Просто интересно. Я иногда использую функцией "get tags from..." и конвертирую фубаром винил рипы, которые cuetools не понимает.
Ну, и что бы 2 раза не вставать - у меня пара простеньких предложений к Григорию:
1. Сделать опцию "add folder to local database" доступной из контекстного меню проводника windows. Это сократило бы количество кликов мыши - открытие cuetools и добавление папки происходит за 2 клика мыши, а не как сейчас - открыть cuetools, проскроллировать и раскрыть все дерево папок чтобы найти нужную, выделить ее и активировать опцию. 2. При запуске cuetools - в проводнике программы открывается последняя активная папка (которая была открыта в cuetools ранее, или с которой работали).
2.1 Перехода к этой папке не происходит, и (если показывается большое количество папок) приходится скроллировать, чтобы найти эту папку. Мне кажется, что было бы удобнее, если бы, при запуске cuetools, в проводнике программы автоматически происходил бы переход к этой последней активной папке.
2.2 Чаще всего, (открывая cuetools) пользователь намеревается работать с папкой, окно которой в данный момент открыто в проводнике windows. Я не знаю - можно ли это реализовать, но было бы удобным, что бы cuetools могла, при запуске, переходить в своем проводнике на ту папку, окно которой в данный момент активно в проводнике windows.
Как вариант - добавить в cuetools чекбокс, (обозвав его, например - "Locate in active folder") при активации которого, cuetools, при запуске, переходит в своем проводнике к той папке, которая активна в проводнике windows. Если же галочка в чекбоксе снята, то cuetools, при запуске, переходит к последней активной папке (как происходит сейчас).

gchudov
просто на cue полагаться, нэ ?
без cue же CT не работает.
значит у нас всегда есть CUE и нужно считать его точным!
Если есть TOC в логе, то сравнивать TOC'ы - полученную и из лога и выдавать в отчет предупреждение, как с DISCID.
ещё делать сравнение pre-gap из CUE и LOG.
и при отличии можно в LOG их исправлять на фреймы.

Вот только в логе исправлять ничего не надо.

Хо, это умеет гора программ - и некоторые из них еще как это умеют! То есть, делают это вне зависимости от форматов, тегов и битрейтов... тут cuetools'у ну оооооочень далеко до них. Ну это мягко говоря по сути бесполезная функция - точнее бессмысленное развлекалово для юзеров.
Но это даже CUE Corrector умеет делать. Ну тут даже комментировать нечего ибо вы сами намедне столкнулись с проблемой конвертации, в которой cuetools был бессилен. А таких проблем можно приводить до бесконечности ибо легче перечислить чего умеет cuetools, чем то чего он в принципе не умеет. неужели он умеет корректировать рипы с ошибками в семплах, делая возможным не перекачивать другой рип, а скачать лишь нужные быйты? Нет, не умеет. А с помощью других программ это сделать возможно. Можете порыться на форуме - я где-то помог пользователям из бракованного рипа сделать оригинальный, не заставляя скачивать рип по новой. Неужели cue tool поддерживает пакетную запись/редактирование/удаление тегов? А многие программы это делают это влегкую. Не говоря про их ассортимент и инструменты работы с ними.
В целом могу сказать, что для рядового пользователя cuetools представляет из себя инструмент усложнения себе жизни, поскольку рутинные и необременительные операции в других программах он превращает в поштучное мучительное действо. Не говоря о том, что круг этих действ весьма ограничен. И любое отступление от него приводит к страшной головной боли у юзеров, в отличие от пользователей других программ.
Некоторый интерес, но тоже ограниченный, cuetools может представлять для вторичных релизеров (тех, кто выкладывает несобственные рипы - вот эта довольно многочисленная армия (по сравнению с первичными релизерами) - кровно заинтересована в проверке рипов, поскольку она их добывает из разных мест и выкладывает на трекерах и проч. И в общем этим кругом людей ее практический интерес ограничивается. Для остальных пользователей, как я уже сказал, она фактически является игрушкой, забавой, которая как и любая игрушка ей пока и останется.
Рано или поздно и вы придете к этому выводу, если ваши потребности немного вырастут в ширину и в объеме по сравнению с теперешним их уровнем.

Странно... если речь не идет о вычислении CRC файлов, то мне не известно ни одной (кроме cuetools) программы. Можно, хотя бы пару (наиболее функциональных) примеров из этой "горы"? А я, наоборот, уверен в исключительной полезности данной функции.. ну по крайней мере - полезности для меня. CUE corrector не умеет делать остального. В той паре случаев, мне как раз не пришлось ничего перекачивать - после применения функции repair рип стал "aссuгately ripped". Эмм.. не понял, что значит "пакетная" запись/редактирование/удаление тегов? Разве, когда CUETools обрабатывает рипы в пакетном режиме, то он не обрабатывает в том же режиме и теги? Как я понял - уникальные безальтернативные функции фубара которые "можно было бы назвать", и "гора программ" обладающих тем же набором функционала, а так же проблемы которые "можно приводить до бесконечности" свелись, в итоге, к ограничению программы по работке только с CD форматом lossles контента? Не буду исключать вероятности того, что мои потребности могут, со временем, как-то измениться, однако в данный момент, я исхожу из своих нынешних потребностей.

Ну так это же вам... А вы зайдите например на руборд и поройтесь там (там поиск есть по названиям и кратким описаниям программ) - много нового для себя откроете... Кто бы сомневался
Погремушки сами знаете у кого вызывают наибольний интерес. Само собой, cuetools удалось превзойти cue corrector как конвертера (ура!). Зато последний умеет делать бааааальшую кучу другого, что и не снилось cuetools, но представляет реальный практический интерес для рядового пользователя, опять же в отличие от cuetools.
Как очевидно, cue corrector предназначен для более серьезных людей, а cuetools - в основном для, скажем менее серьезного пользователя. А как известно, лучшая реклама, как раз из детских уст... вот его и распиарили (вы тому яркий пример). Ну так там ничего бинарного повреждено и не было. А был бы хоть один байт поврежден и сидели бы вы с cuetools в луже. А ваше "великое таинство исправления рипа" заключается в перенесении нескольких байт с начала wav файла в конец или наоборот в зависимости от знака корректируемого офсета - делается в любом hex редакторе двумя кликами. Не говоря о специализированных утилитах. Только смысл этого действа по большому счету непонятен, поскольку рип от этого лучше не станет (хуже - может, если ненулевые байты есть в конце или начале рипа). Другое дело, как я уже говорил ранее, когда у вас на руках более одного рипа и нужно выбрать самые достоверные, но опять же ничего двигать не нужно. Можно сравить файлы с hex сдвигом - если они по идее должны быть идентичными, а если они разные по звуковому потоку, то AR не поможет, если они оба в ней присутствуют, потому как число совпадений не говорит в общем случае о точности - вполне возможно, что более качественный рип получен на более качественном приводе, кои всегда в меньшинстве, по сравнению с ширпотребом, который очевидно главным образом и наполняет AR. Это значит - манипуляции с тегами сразу с неограниченным числом аудиофайлов разных форматов.
Наример, нужно вам убрать двойные пробелы, пробелы в начале поля и в его конце сразу во всех тегах/полях и во всех файлах вашей медиатеки. Для нормального редактора тегов - рутинная операция выполняемая парой кликов. Это простейший пример. А реальные задачи куда более сложные встречаются. Так что советую вам учиться и учиться, пока не поздно, чтобы не возникла ситуация, что вам легче долго мучиться, чтобы решить задачу, нежели освоить прием, как сделать это без напряга одним пальцем за пару минут. Скажу вам по секрету, вы не хрена не поняли и врядли поймете, поскольку обучаемость имеет у вас крайне низкий коэффициент. А если вспомнить, что интеллектом, в интерпретации великих, называют прежде всего способность к познанию, то сами понимаете какие напрашиваются выводы. Я вам дал информацию - что существует то и то. А вы ей в принципе не способны воспользоваться. Это не поиск черной кошки в темной комнате, которой там нет. Это всего-лишь погуглить нужно и не более. Причем можно и на русском языке. Задача для современного пятиклассника... но вы, похоже, и на это не способны, кроме препирательств основанных на вашей "точке зрения":
На одной из своих лекций Давид Гильберт сказал:
– Каждый человек имеет некоторый определенный горизонт. Когда он сужается и становится бесконечно малым, то превращается в точку. Тогда человек говорит:"Это моя точка зрения".
(Из книги: "Физики шутят")
P.S. Я бы мог устроить вам лекбез, но как показывает опыт, это благодарная вещь в cлучае пользователей, к которым вы не принадлежите. А попусту тратить время мне не хочется. И даже пишу я это в большей степени не для вас, а для пользователей способных использовать информацию себе во благо, а не отпинывать ее или отвергать, только потому, что она расходится с их "точкой зрения".
_____________
Это уже не для вышеозначенного пользователя. А как дополнительные мысли вслух по поводу cuetools, о которых я забыл упомянуть ранее.
Справедливости ради должен заметить, что в этой программе лично мне кажется интересной, то есть достаточно уникальной - функция поддержки скриптов. Я говорю не о самих скриптах, а об идее. В принципе она могла бы развиваться на благо пользователей - то есть, в ней есть чего развивать, потенциал. Но на данном этапе она фактически в зачаточном состоянии и главное недоступна рядовым пользователям для активного использования (написание собственных скриптов и т.д.), то есть она декларирована, продемонстрирована, но реальный ее функционал эквивалентен обычным кнопочным программам.
P.S. Все сказанное относится с cuetools как таковому. К CUE Ripper'у оно не относится, по причине недостаточной информации о нем у меня.