У меня вопрос к админам.
Если заливают трек-куе,в 99% куе идет WAV,а теперь скажите куе для чего вообще....(чтоб записать скопированные треки на диск копией),хорошо,но...сами файлы Flac,на данный момент ни одна программа работающая с куе файлами для записи,не запишет такой релиз,тогда для чего собственно нужен такой куе в не рабочем состоянии,его надо редактировать...,можно и записать треки без куе,тогда вообще зачем он нужен в раздаче?

Так же в таких раздачах присутствует M3U,а вот он то для чего в раздаче лосслесс,может стоит тогда или размещать рабочий куе,или вообще не указывать и не размещать ни мнимый CUE c M3U а одни треки.

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

P.S Клуб от этого только прибавит репутацию в качественных раздачах,и их ни как не станет меньше

xDDDx, все правильно

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

использовать куе как плейлист это не очень правильно, поэтому добавляют файл плейлиста.

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

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

И еще,что касаемо самого куе,вот релиз взят с ваты или вафлях не знаю,но вот куе


Такой куе не запишет не в вав ни в флак,хотя суе в еас создается автоматом и в потрековом снятии,значит или подправляли отчет аес или еще хз что,но не может еас снять пол треков диска с одним индексои а другую половину с двумя.

И где гарантии того что у нас таких суе еденицы,может в логах стоит размещать суе в тексте

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




а вот окно с загруженным исправленным .cue



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

вердикт: можно добавить в задаче дополнительный .cue для flac/ape/wv, но исправлять оригинальный .cue (Noncompliant cuesheet созданный ЕАС) по своему усмотрению запрещено.

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

TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 4:32.07 | 0 | 20406
2 | 4:32.07 | 6:13.33 | 20407 | 48414
3 | 10:45.40 | 5:09.24 | 48415 | 71613
4 | 15:54.64 | 4:42.14 | 71614 | 92777
5 | 20:37.03 | 4:24.02 | 92778 | 112579
6 | 25:01.05 | 4:56.69 | 112580 | 134848
7 | 29:57.74 | 3:55.73 | 134849 | 152546
8 | 33:53.72 | 4:51.54 | 152547 | 174425
9 | 38:45.51 | 1:16.24 | 174426 | 180149
10 | 40:02.00 | 4:52.62 | 180150 | 202111
11 | 44:54.62 | 5:42.59 | 202112 | 227820
12 | 50:37.46 | 3:06.67 | 227821 | 241837
13 | 53:44.38 | 6:11.12 | 241838 | 269674


Где правда??

Дим, я не знаю (пока ) где правда....но истина в том что ЕАС генерирует эти файлы именно так.

а вот отрывок из инструкции который ты привел как пример в раздаче Rodgers https://losslessclub.com/details.php?id=26895



а вообще статья очень интересная и познавательная...советую всем ознакомится.

ЗЫ: автору отдельное спасибо

Вот посмотри специально снял для тебя рип в двух вариантах,могу скинуть архивом если надо

ENIGMA






Secret Service






Сделал два разных релиза,чтоб было более видно



Отличие первого релиза образа в том что альбом CDExra,поэтому экстра часть не вошла в образ,а вот в трековом варианте она отобразилась.


Теперь наверное главное что я до вас до всех пытаюсь донести Редактировать куе для записи не надо,это и так понятно,можно добавлять куе под формат,НО размещать его в текстовом виде в логах нужно.А что касаемо этого рипа то он кривой,как бы вы его не защищали.
И так как мы говорим про tracks + .cue,то если кривой куе то и оценка должна быть никак не R,и таких правильных рипов у нас в клубе 90%

Всё правильно, полностью согласен.

Опять нет! Размещать в визарде (в оформлении раздачи) да и в самой раздачи нужно оригинальные логи и куи, программа EAC сама разберётся какой лог и куй какому рипу давать (чтобы сохранить информацию о точной копии Audio-CD и CDExra тоже)
А понижать оценку нужно совсем другим раздачам.
Вот этой:
http://losslessclub.com/details.php?id=19397
За незаполненный тег и неправильный аккуратив (AccurateRip) с потерянным нулевым прегэпом первого трека.

Вот этой:
http://losslessclub.com/details.php?id=11696
Здесь очень яркий и видимый Shelf на 16 kHz, и что это такой ремастер или мастеринг я не поверю .. АП

Коллеги, прочитал ваш спор от начала и до конца.
Очень благодарен и Rodgers, и xDDDx за то, что не скатились до базарной ругани и перехода на личности.
Присоединяюсь к MisterEco, ознакомиться со статьей действительно очень полезно для всех, имхо. Но не нужно слепо доверять статьям и постам (включая этот :-)), подобные споры может разрешить только официальный стандарт, для нашего случая это Red Book. Кто не обладает этой книгой, советую в поиске google запросить строку "iec 60908 скачать" и приобрести ее официально за 112$. Ни в коем случае не советую скачивать ее бесплатно с сайта thepiratebay (ссылка там же, внизу страницы) или аналогичного!!! Также советую прочитать первую главу книги Криса Касперски «Техника защиты компакт-дисков от копирования». Она для программистов, но в первой главе теория по структуре CD с картинками.

Хоть и не советую доверять всецело этому посту, но надеюсь что он вам хоть немножко, но поможет. Без Красной книги CD вы вряд ли до конца разберетесь в нем. Поехали.

Для начала, нам стоит четко для себя уяснить: нет стандарта, который описывает формат файла .cue. Чтобы избежать проблем при записи, необходимо следовать правилу: использовать для записи ту программу, в которой .cue создан. Другие программы не обязаны "понимать" все возможные варианты форматов .cue. Но в независимости от синтаксиса конкретного .cue файла, главной информацией в нём как раз и является количество и позиции каждого индекса в каждом треке, как мы увидим далее, это и есть то, что называют «структурой диска».

Преамбула.
Каждому сектору аудиоданных (2352 байта), соответствует блок субканальных данных (2 байта синхронизации + 96 байтов, биты которых имеют имена: PQRSTUVW). Аудиоданные и субканальные данные хранятся отдельно друг от друга, но взаимосвязаны. Значащими являются только два из восьми: P и Q.
Немного «магических чисел» для CDDA:
2352 = размер сектора аудио CD
2 = количество каналов (стерео)
2 = размер в байтах одного сэмпла (16 бит)
2352 : 2 : 2 = 588 = количество сэмплов для каждого канала, которые хранятся в одном секторе аудио.
44100 = частота дискретизации (количество сэмплов для каждого канала 1 секунды звучания)
44100 : 588 = 75 = количество секторов аудиоданных в 1 секунде звучания.

Откроем Стандарт.
Нас интересует раздел 17 - субканальные данные.
Пункт 17.4. Канал P используется для индикации следующего трека (если субканал P = 1 для любого сектора аудиоданных - с этого сектора начался новый трек). В этом пункте есть много полезной информации, не относящейся к спору, пересказывать не буду.

Но более интересным для нас является канал Q, особенно его mode 1 for DATA-Q (17.5.1).
Там изображены структуры двух типов.
Мы видим, что TOC фактически хранится в Q субканале Lead-In трека (первая структура).
Что же за информация хранится в TOC?
Посмотрим на первую структуру: видим, что Lead-In имеет номер трека (TNO)=00
Поле Point - номер пользовательского трека (от 01 до 99), на который указывают: Pmin, Psec, Pframe - минуты, секунды, фреймы этой же структуры, т.е. это позиция трека с номером Point относительно программной области диска, причем, есть уточнение (X не равно 0)!!!! Что за X??? Пока не знаем.
Смотрим на другие поля и видим, что никакого намека на прегапы нет. Т.е. зная только TOC, мы не можем сказать, есть ли у определенного трека прегап. Мы можем узнать только позицию начала трека в формате MSF (минуты, секунды, фреймы) с номером, записанным в поле Point.
Но что же обозначает вышеупомянутый X, да и вообще, что такое прегап?
Возвращаемся в начало 17.5.1 и рассмотрим вторую структуру. Субканал Q этого типа соответствует каждому сектору аудиоданных. Эта структура похожа на первую, за исключением того, что нули вместо TNO исчезли, теперь здесь будут хранится номера от 01 до 99 (максимум) для текущего пользовательского трека и АА - для Lead-Out. А за ним сразу поле X. Ага! Вот он! Идем в описание, и видим, что X — это индекс внутри трека, причем, если X = 00 - это пауза между треками! Так вот, что такое прегап! Сектора аудиоданных, которым соответствует субканал Q, в поле индекса X которого 00, и есть сектор прегапа (1/75 секунды прегапа). Технически, авторы диска могут хранить там реальные аудиоданные, только воспроизводиться на плеере они вряд ли будут (зависит от прошивки). Кроме того, автор может разбить трек максимум на 99 логических частей, и эта информация может сохранится на CD. Теперь мы также можем с уверенностью сказать, что в TOC хранится указатель обязательно на ненулевой индекс трека (уточнение выше "Х не равно нулю" жирным, помните?) и в подавляющем большинстве случаев этот индекс = 01.
Кроме того, субканал Q любого сектора аудиоданных хранит в полях MIN, SEC, FRAME - адрес сектора аудиоданных, относительно начала трека (тут же видим, что в одной секунде 75 (вот и "магическое число") фреймов (секторов) от 0 до 74). А еще есть AMIN, ASEC, AFRAME, в которых хранится абсолютное время (время сектора аудиоданных относительно начала диска, вернее программной области).

Давайте обобщим и представим себе структуру "полезной" области диска. Сначала (по Стандарту) прегап (индекс 00) первого трека от 2 до 3 секунд. Потом первый трек, начинающийся с индекса = 01. Здесь ремарка. Время в структуре TOC обязательно указывает на ненулевой индекс трека (в 99,9999...% случаев - это индекс = 01. Если TOC указывает, например, на индекс = 02 конкретного трека, это значит, что относительно TOC часть трека скрыта, и прослушать эту часть можно либо с помощью перемотки назад, либо последовательным прослушиванием). Потом возможен прегап второго трека (индекс = 00 второго трека). Как EAC или аналогичная программа его ищет? Грубо говоря, запрашивает субканальный блок для секторов аудиоданных трека по очереди с начала, и если субканал P = 1 и в субканале Q поле индекса X = 00 - перед нами прегап. Он продолжается до 01 индекса второго трека и, если судить по TOC, как бы находится во временнОм диапазоне первого трека, как бы в его конце. Поэтому EAC в логе честно сообщает, что присоединяет аудиоданные, расположенные в прегапе, к предыдущему треку (Appended to previous track), чтобы не было разногласий со структурой TOC. Однако на самом деле, технически, прегап принадлежит следующему треку, и об этом не нужно забывать. Если прегап обнаружен, то текущий трек на самом деле короче, чем показывает нам подсчет длины трека по адресам TOC ровно на длину прегапа. И так далее для каждого пользовательского трека.

Теперь давайте посмотрим на четвертый и пятый треки "скандального релиза" http://losslessclub.com/details.php?id=26895:


Этой структурой EAC как бы пытается нам сказать: «Я записываю в файл 04….wav четвертый трек с его начала (00:00.00), а после этого приписываю к этому же файлу, начиная с адреса 04:40.36, часть пятого трека, начинающуюся с индекса 00 и до индекса 01». Можем посчитать длину прегапа. Заглядываем в TOC: адрес индекса 01 пятого трека = 20:37.03 минус адрес индекса 01 четвертого трека = 15:54.64, получаем общую длину четвертого трека с длиной прегапа пятого = 04:42.14 и вычитаем позицию начала прегапа 04:40:36 = 00:01.53 (не забываем, что в секунде 75 секторов (фреймов), а не 100). Посмотрите на скрины, которые выложил MisterEco. Аналогично и с другими «аномальными треками».

Что будет, если мы не удаляем информацию о нулевом индексе пятого трека из .cue?
При записи EAC, анализируя этот .cue будет знать, что нужно записать в субканалы P = единицы, а в поле индекса X субканала Q нули, соответствующие секторам аудиоданных начиная с адреса 04:40.36 и нужной длины. Таким образом прегап будет сохранен, настоящая длина четвертого трека не потерпит изменений (04:40.36), а структура диска будет максимально соответствовать оригиналу.

Что будет, если мы удалим информацию о нулевом индексе пятого трека?
При записи EAC посчитает аудиоданные всего файла принадлежащими четвертому треку и не создаст прегап на диске. Фактически четвертый трек станет длиннее на величину прегапа, по сравнению с первым случаем (04:42:14). TOC будет таким же, как и в первом случае, но информация о прегапе записана на диск не будет (в субканалы). При рипе уже этого, записанного диска, индекса 00 пятого трека в .cue, естественно, не будет.

Итоги.

• Технически рип выглядит правдоподобным, другими словами прямой :-)
• EAC не только может, но и обязана снять половину треков с одним индексом, а половину с двумя, а если есть трек с 5 индексами, то в .cue должно быть 5 индексов, если такова структура диска.
• Количество индексов в любом треке может быть произвольным от 1 до 99 пользовательских + нулевой (пауза), т.е. до 100. Действительно, допустим я композитор (хотя мне очень трудно это представить). Я написал музыкальное произведение, состоящее из трех частей: вступление, основная часть, окончание (очень оригинально :-) ). Причем, вступление = 2 минуты, основная часть = 50 минут, а окончание = 3 минуты. Основная часть — целостная, я не хочу разбивать ее на треки, но есть смена настроений звучания. С другой стороны навигация по ней для слушателей будет неудобной. Стандарт CD позволяет мне проиндексировать ее, таким образом проблема будет решена. Аналогично реализована индексация DVD фильмов (переход к следующей части фильма). Тогда вступление будет иметь один индекс, основная часть, например, 20, и заключительная часть 1 индекс. И все это отразится в .cue при рипе такого CD.
  Или другой пример: я хочу записать CD со звуками природы (например 600 коротких звуков), причем структурировано. Могу разбить так: первый трек - щебет птиц = 99 индексов, второй трек - щебет птиц продолжение = 21 индекс, третий трек - шумы моря = 10 индексов... Если не использовать индексы трека, то записать получится только 99 (максимальное количество треков на диске). При использовании индексов до 99*99 + при надобности, можно использовать и паузу, тогда вообще до 99*100.

Надеюсь этот пост был вам полезен в поисках правды.

P.S. Rodgers, вы с достоинством выдержали давление xDDDx, но с последним постом вы погорячились, имхо. К вам возникло несколько вопросов :-) :

• Зачем заполнять тег «Исполнитель альбома» для релиза с одним «Исполнителем»? Понимаю, если это компиляция произведений разных исполнителей, но, например, одного композитора, но здесь-то зачем?...
• Неверный Accurate – обычное дело, другой пресс диска был зарегистрирован первым. Кто первый встал, того и тапки.
• Насчет прегапа первого трека, что вы имели в виду? В вашем релизе, который мы разбирали, он тоже потерян.
• Насчет альбома Барыкина: оценка ставится за правильное снятие рипа, качество аудиоданных остается на совести сборщика компиляции и не может учитываться. Если предложите более качественный рип, мы его с удовольствием заменим :-) Только, думаю, для этого альбома, это будет проблематично…