Для данного аудиофайла определите, закодирован ли он в формате с потерями или в формате без потерь. Для целей этой задачи необходимо классифицировать только следующие форматы:
правила
- Если ввод принимается в форме имени файла, не следует делать никаких предположений относительно имени файла (например, расширение не гарантируется для формата правильно или даже не присутствует).
- Во входных файлах не будет метаданных ID3 или APEv2.
- Могут использоваться любые два уникальных и различимых выхода, таких как
0
и1
,lossy
иlossless
,foo
иbar
, и т. Д.
Тестовые случаи
Контрольные примеры для этой задачи состоят из расположенного здесь zip-файла, который содержит две директории: lossy
и lossless
. Каждый каталог содержит несколько аудиофайлов, которые представляют собой синусоидальные волны 440 Гц по 0,5 секунды, закодированные в различных форматах. Все аудиофайлы имеют расширения, соответствующие указанным выше форматам, за исключением A440.m4a
(это аудио AAC в контейнере MPEG Layer 4).
Ответы:
Желе ,
75 байтФорматы с потерями возвращают 0 , форматы без потерь возвращают 1 .
Попробуйте онлайн! (постоянные ссылки в Gist)
Фон
Форматы, которые мы должны поддерживать, имеют следующие магические числа, т.е. они начинаются с этих байтов.
Записи с отступом - это контейнеры для предыдущего формата, которые появляются в тестовых примерах.
?
обозначает переменный байт..
обозначает непечатаемый байт. Все остальные байты отображаются в виде символов ISO 8859-1.Посмотрев только на второй байт, мы можем легко определить формат:
Форматы без потерь имеют заглавную букву в качестве второго байта, а форматы с потерями - нет.
Как это устроено
источник
C
828032 байтаВдохновленный ответом @Dennis , это может быть значительно уменьшено:
Передайте данные файла в stdin. Возвращает 0 для потерь или ненулевое значение для потерь.
Или оригинал дольше проверяю:
Передайте данные файла в stdin. Возвращает ненулевое значение (1) для потерь или 0 для потерь.
Из того, что я могу сказать, все форматы, которые вы перечислили, имеют отдельные магические числа (кроме AIFF / WAV, но оба они в любом случае без потерь), так что это просто проверяет это магическое число на известное значение без потерь. Это
*v&&
просто для защиты от сопоставления файлов, которые начинаются с нулевого байта (M4A).Я включил значения, которые я нашел в спецификациях (
fLaC
= FLAC,RIFF
= WAV / AIFF,TTA1
= TTA), иFORM
= AIFF иFFM2
= TTA взяты из предоставленных примеров файлов (я могу только догадываться, что это форматы обертки или более поздние версии).Или более короткая, похожая на обман, альтернатива:
Bash + файл, 61 байт
Принимает имя файла в качестве аргумента. Возвращает 0 для потерь или ненулевое значение для потерь.
Делает именно то, что вы ожидаете; спрашивает,
file
что это за тип файла, затем проверяет известные шаблоны. Совпадения TTA: d
(: data
), совпадения AIFF / WAVIF
и совпадения FLACFL
. Ни один из результатов без потерь не соответствует ни одному из них, и я протестировал, что он все еще работает, если имена файлов удалены.Тестирование:
источник
file
что в любом случае не доверяет расширениям (для многих пользователей переименование png в jpeg - это то же самое, что преобразование!)GS2 , 3 байта
Форматы с потерями возвращают 0 , форматы без потерь возвращают 1 .
Попробуйте онлайн! (постоянные ссылки в Gist)
Фон
Форматы, которые мы должны поддерживать, имеют следующие магические числа, т.е. они начинаются с этих байтов.
Записи с отступом - это контейнеры для предыдущего формата, которые появляются в тестовых примерах.
?
обозначает переменный байт..
обозначает непечатаемый байт. Все остальные байты отображаются в виде символов ISO 8859-1.Посмотрев только на второй байт, мы можем легко определить формат:
Форматы без потерь имеют заглавную букву в качестве второго байта, а форматы с потерями - нет.
Как это устроено
источник
JavaScript (ES6), 20 байт
объяснение
Принимает содержимое файла в качестве входных данных и возвращает ,
true
если файл является без потерь или ,false
если он выполняется с потерей данных путем тестирования первого символа этого входа , чтобы увидеть , если этоf
,F
,R
илиT
.Попытайся
Вставьте содержимое файла в
textarea
.Второе усилие,
8163 байтаИзвлекает содержимое файла с предоставленного URL, который оказался излишним.
Первое усилие,
14611689 байтНеверно, так как типы MIME привязаны к расширениям, и, очевидно, заголовки ответа квалифицируются как дополнительный ввод.
источник
AddType <mime> <extension>
или IIS<MimeMap>
. Конечно, определенная установка или инструмент для размещения файлов могли бы провести надлежащую проверку, и это было бы целесообразно, чтобы выбор сервера был частью ответа (поскольку именно сервер определяетЧип , 11 байт
Бесстыдно воспроизведенный ответ Желе Денниса в Чипе.
Возвращение без потерь, возвращение
0x0
с потерями0x1
.Попробуйте онлайн , ссылки в гисте (спасибо Денису за стратегию TIO здесь)
Объясните!
Эта часть является служебной: она
S
убивает первый байт иt
завершается после второго.Это мясо решения. Каждый входной байт доступен по битам
HGFEDCBA
. ЕслиG
это множество, иF
нет, это означает , что байты находятся в пределах диапазона0x40
от0x5f
(что примерно эквивалентно «верхнего регистра», и достаточно хороши для выполнения этой задачи под руку).Однако, для экономии байтов, я инвертирую это решение из
G and (not F)
в(not G) or F
, так как или может быть неявным в Chip.Это результирующее значение true / false затем помещается в
a
, который является младшим битом вывода. (Все остальные биты будут равны нулю). В TIO я запускаю вывод через hexdump, чтобы значения были видны.Эквивалентно, в C-ish можно сказать что-то вроде:
источник
Cubix, 16 байтов
Чистая форма:
Попробуй сам
Вы должны ввести десятичные байтовые значения файла в отдельный список. Разделитель не имеет значения, достаточно всего, что не является цифрой или знаком минус. Код действительно заботится только о первом байте, поэтому вы можете оставить остальную часть файла, если хотите. Программа выводит
0
как без потерь, так и1
с потерями. Попробуй это здесь ! Вход по умолчанию использует заголовок FLAC.объяснение
Хорошая вещь о файлах состоит в том, что (почти) все они имеют так называемую магию. Это первые несколько байтов файла. Хорошее программное обеспечение проверяет не расширение файла, а волшебство файла, чтобы увидеть, сможет ли оно обработать определенный файл.
Деннис нашел способ использовать эту магию, чтобы найти тип сжатия, но тот факт, что он отбросил первый байт, заставил меня захотеть придумать метод, который использовал первый байт, а не второй. В конце концов, это сообщество о сохранении байтов.
Вот список первых байтов разных типов файлов. Я разделил их на две группы: с потерями и без потерь. Вот значения их первого байта в десятичном, шестнадцатеричном и двоичном виде. Вы можете увидеть шаблон уже ...
Шаблон, который я увидел, состоял в том, что второй бит (считая слева направо) всегда был включен в байтах «без потерь», а пятый бит был всегда выключен. Эта комбинация не отображается ни в одном из форматов с потерями. Чтобы «извлечь» это, мы просто сделали бы двоичное И (by
0b01001000 (=72)
) и затем сравнили бы с0b01000000 (=64)
. Если оба равны, формат ввода без потерь, в противном случае это с потерями.К сожалению, у Cubix нет такого оператора сравнения, поэтому я использовал вычитание (если результат равен 64, это дает 0, а в противном случае - 8, -56 или -64. Я вернусь к этому позже.
Сначала давайте начнем с начала программы. Двоичный И делается с помощью
a
команды:Затем мы сравниваем с 64, используя вычитание (обратите внимание, что мы ударяем зеркало, которое отражает IP на верхнюю грань [первая строка, второй символ, указывающий на юг] в середине этой части).
После того, как IP обернут IP
u
, мы используем некоторый поток управления для перемещения a1
в стек, если (и только если) вершина стека отлична от нуля:После обтекания куба мы нажимаем на
<
инструкцию, которая указывает IP на запад на четвертой строке. Все, что осталось сделать, это вывести и завершить.Итак, программа выводит
0
как без потерь, так и1
с потерями.источник