Linux, HiRes аудио и .cue

Очевидно, shntool у тебя ванильный, бери или мой патч, или по ссылке выше, и все у тебя будет работать.

Так вот к этой проверке я потихоньку и продвигался (исходя из того, что старый баг, скорее всего, у ТСа исправлен).

$ flac -c -d -s Ixnay\ on\ the\ Hombre.flac | xxd -l 1024
00000000: 5249 4646 60e2 c5ab 5741 5645 666d 7420  RIFF`...WAVEfmt 
00000010: 1000 0000 0100 0200 00ee 0200 0094 1100  ................
00000020: 0600 1800 6461 7461 3ce2 c5ab 23e2 00e7  ....data<...#...

Значит, у ТСа 3ce2 c5ab (le) --> ABC5E23C = 2881872444 байт, что >2GB. И как раз 2881872444 байт * 8 бит/байт / (24 бит/сэмпл * 2 (канала)) = 480312074 сэмпл сходится с выводом soxi. Для длительности: 480312074 сэмпл / 192000 сэмпл/с = 2501.625 с = 41.693756 мин.

Значит, в самом начале идут не заковыристые теги или ещё что-то помещённое в RIFF-контейнер (что тоже можно было предположить, если бы у ТСа была пофикшенная версия), а сразу нужные WAVE данные, и shntool спотыкается на том, что уже более 2-х лет назад было исправлено и обсуждено flacon: Splitting 24 bit 192 khz flac files (closed).

На всякий случай, уточню: shntool последней, 3.0.10 версии?

Теперь надо будет спрашивать не просто «последней», а последней из уважаемого дистрибутива. И надо бы вовсе сорвать с того сайта с shntool ярлык «upstream».

Спасибо. Видос зачётный!

Анализатор спектра из видео, если вдруг кому надо. Выглядит годно и есть логарифмическая шкала частот. FFTW, GTK2.

матчасть

Матчасти там, вроде, совсем немного. Всё, что выходит за пределы формул со 100% воспроизводимостью, уже не то. А что делать с предвзятостью? Тут:

... The FLAC file is also smaller than the WAV, and so a random corruption would be less likely because there's less data that could be affected.

я вижу, как замолчан тот факт, что когда кусочек всё же повредится, то в FLAC потеряется больше данных, чем в WAV. А сколько там ещё мест, в которых я не заметил подобной лёгкой манипуляции фактов...

Ну так ты из контекста не вырывай:

In the event that Wired was referring to hardware corruption of data files (disk failure, memory failure, sunspots), FLAC and WAV would both be affected. A FLAC file, however, is checksummed and would detect the corruption. The FLAC file is also smaller than the WAV, and so a random corruption would be less likely because there's less data that could be affected.

И где здесь манипуляция фактами? Если аппартный сбой, пострадают оба (у flac хотя бы чексуммы есть, чтобы это обнаружить). Но вероятность меньшего по объему файла пострадать, очевидно, меньше. Если же это произойдет, тебе будет все равно сколько там данных покоцалось.

Манипуляция в том, что подчёркнуто преимущество, но замолчан недостаток в менее вероятном случае повреждения потерять большее кол-во данных.

Я исходил из того, что не всё равно. И отсутствие большего кол-ва данных в FLAC будет ещё сильнее резать слух, чем короткий щелчок в WAV.

Ощем итог (для всех тех бедолаг, кому с этим «посчастливится» столкнуться):

• Можно закостылить мнимый последний трек в куешку и таки использовать shntool
• Есть пофикшенный shntool
• Любители гуёв могут просто взять deadbeef
• Можно разрезать через ffmpeg (скриптик на питоне)

P.S. Для себя выбрал «скриптик». Возможно когда-нибудь соберусь с духом и доведу его до ума чтоб было с блекджекком и шлюхами аргументами и автоопределением невозможности юзать copy фильтр.

Можно разрезать через ffmpeg (скриптик на питоне)

Так как там с гранулярностью у flac (точность до 1/5/10 секунд)?

Вроде до миллисекунд показывает. Конкретно этот альбом несколько странно обрезался - у каждого трека выставлена длина всего альбома (может я какой-нибудь флаг забыл выставить?), хоть и проигрывается ровно столько сколько по длине сам трек должен быть и весит вроде нормально...

«проблемы» звуко*бов просто пособие для мозговеда )))
OCD во все дыры, как минимум )))