Странный у них подход к обозначению lossless. Как уже справедливо писали, если после обратной распаковки мы не получаем побитово точно такой же файл (в его музыкальном содержимом, не говоря о контейнере и метаданных), это всё равно не lossless, хотя бы технически (не говоря уже об mp3). Так что в этом смысле обозначение признака "Lossless" оказывается не совсем корректным и не совсем "real".-)
Не говоря уже о том, что в этом поле заметны 2 более важных архитектурных недостатка: в одном поле комбинируются значения двух отдельных признаков (lossless/lossy и условное качество звука normal/high, видимо, исходя из диапазонов битрейтов), и при этом значение одного может замещать и не оставлять места для значения другого, не будучи разбитыми на 2 отдельных поля.
И, опять таки, будучи нормализованным, поле с признаком lossless/lossy стоило бы упростить и сделать булевым со значениями типа 1/0, а условное качество звука low/normal/high, которое тоже проще обозначать числами, как рейтинг трека из нескольких "звёзд".
Касаемо поля "codec".
У эппловских кодеков, кажется, контейнер и расширение файлов одинаковые (aac), но lossless-кодек при этом называется ALAC, поэтому для таких lossless-версий нужно указывать "alac", в том числе во избежание путаницы (пусть и в дополнение к отдельному признаку lossless).
Возможно, значение поля обозначает именно расширение исходного файла независимо от его содержимого. В таком случае, если это поле содержит корректные данные, оно при этом неправильно именовано, и наоборот. Вспоминается знаменитая фраза про две основные проблемы программирования.-)
Касаемо поля "bitrate".
Насколько я понимаю, в случае lossless (по крайней мере, в случае FLAC) главное - степень сжатия в условных единицах, а битрейт не имеет большого значения, технически может оказаться каким угодно, не обязательно целым числом и не обозначает условное качество звука, которое в этом случае имеет смысл градировать по битности и частоте дискретизации исходного файла (хотя файлы большого объема трудно быстро перегонять по сети и кэшировать локально, не блокируя при этом realtime-воспроизведение, так что, скорее всего, сейчас lossless представлен исключительно по спецификации CD Audio).
А в случае lossy, наоборот, величина битрейта почти всегда фиксирована (кроме случаев VBR, переменного битрейта по ходу воспроизведения), является синонимом условного качества звука (как это было на старых не очень качественных mp3-кодеках) и по сути маскирует этот признак.
Возможно, для значений поля используют только целые числа в диапазоне из нескольких известных значений (подобно enum), а иначе ноль (хотя, опять же, логичнее было бы оставлять NULL как отсутствие значения), отбрасывая все остальное, но при таком подходе для значений FLAC можно отметить сразу 2 недостатка: неконсистентость заполнения данными (в поле с каким-то значением его то указываем, то нет, хотя стоило бы указывать всегда) и опосредованное дублирование информации (ноль по сути работает как избыточный логический флаг, обозначающий lossless FLAC, причём не по принципу истина - 1, ложь - 0, а наоборот, как exit-коды приложений в Linux). А фиксированные значения битрейта, наоборот, опосредованно обозначают собой в основном, если не полностью только lossy-записи.
Не стоит называть эти методы магическими. В них нет никакой магии, когда мы получаем результат, но не знаем, что происходит внутри в процессе его получения. Эти методы стоит называть специальными или предзаданными (predefined), т.к. они предназначены для решения конкретных задач понятным описанным в документации способом и не могут быть переопределены.
По умолчанию было бы логично, чтобы бесплатный период ожидания включался автоматически (по координатам GPS или мобильной сети), когда машина приближается на некое фиксированное расстояние до заданной при заказе точки посадки или до то самого устройства, с которого сделан заказ, если клиент перемещался уже после вызова. Иначе здесь очевидно есть слабое место с возможностью манипуляций со стороны недобросовестных водителей, сам с таким сталкивался.
Очевидно, "Fluent Python" Лусиану Рамальо, в русскоязычном переводе - "Python - К вершинам мастерства". Недавно как раз вышло обновлённое второе издание, из удобств, кроме прочего - в твёрдом переплёте, в отличие от первого издания.
Немного неожиданный подход к оформлению статьи. По умолчанию ожидаешь увидеть в фотографиях авторов книг, а там оказываются сотрудники, рекомендующие книги этих авторов.-)
Я слушал бобины на отцовском "Маяке" (точную модель не помню), аппаратуру высшего класса не покупал (хотя видел "Олимп", как на фото, в одной местной студии). Конечно, в тот момент, пока мода снова не возродилась, такое "железо" стоило гораздо дешевле, чем сейчас.
Ну, я родился в конце 1980-х, и на рубеже веков успел приобщиться к бобинным записям, которые делались, видимо, в первой половине 1980-х. Они у меня до сих пор хранятся. Кое-что из классики (например, первый альбом The Doors или второй альбом Dire Straits) я в первый раз услышал именно с бобины.
Собственно, строчка про Атлантиду - из одноимённой песни "Воскресения".-)
В Советском Союзе за "железным занавесом" это была целая андерграундная субкультура, которая, очевидно, ещё ждёт своих исследователей.
Люди записывали и перезаписывали альбомы любимых групп на бобины (привычные уже потом аудиокассеты пришли к нам только на рубеже 1980-х - 1990-х). При этом хорошо, если источник записи был на пластинке, взятой на время. Иначе приходилось многократно переписывать одну кассету с другой (так называемые generations, или последовательные "поколения" перезаписи), постепенно теряя в качестве звука.
Имеющиеся записи тщательно и с любовью каталогизировались в тетрадях. Каждой бобине в коллекции иногда присваивался свой порядковый номер, указывались не только выходные данные какого-то альбома, но иногда воспроизводились логотипы групп, записывались англоязычные тексты (если они имелись) и т.п.
Как пелось в одной песне, "дивный берег Атлантиды"...
Добавлю обратную связь по коду Python: лучше использовать аннотации типов, чем явно указывать в названиях параметров функции/возвращаемых значениях их тип.
Можно также упомянуть ReadyAPI от разработчиков SOAP UI, компании SmartBear. Продукт платный, но позволяет тестировать разные типы API, в последних версиях, кажется, даже GraphQL.
Вы пытаетесь в этом убедить читателей или самих себя? :-D
Касаемо поля "realQuality".
Странный у них подход к обозначению lossless. Как уже справедливо писали, если после обратной распаковки мы не получаем побитово точно такой же файл (в его музыкальном содержимом, не говоря о контейнере и метаданных), это всё равно не lossless, хотя бы технически (не говоря уже об mp3). Так что в этом смысле обозначение признака "Lossless" оказывается не совсем корректным и не совсем "real".-)
Не говоря уже о том, что в этом поле заметны 2 более важных архитектурных недостатка: в одном поле комбинируются значения двух отдельных признаков (lossless/lossy и условное качество звука normal/high, видимо, исходя из диапазонов битрейтов), и при этом значение одного может замещать и не оставлять места для значения другого, не будучи разбитыми на 2 отдельных поля.
И, опять таки, будучи нормализованным, поле с признаком lossless/lossy стоило бы упростить и сделать булевым со значениями типа 1/0, а условное качество звука low/normal/high, которое тоже проще обозначать числами, как рейтинг трека из нескольких "звёзд".
Касаемо поля "codec".
У эппловских кодеков, кажется, контейнер и расширение файлов одинаковые (aac), но lossless-кодек при этом называется ALAC, поэтому для таких lossless-версий нужно указывать "alac", в том числе во избежание путаницы (пусть и в дополнение к отдельному признаку lossless).
Возможно, значение поля обозначает именно расширение исходного файла независимо от его содержимого. В таком случае, если это поле содержит корректные данные, оно при этом неправильно именовано, и наоборот. Вспоминается знаменитая фраза про две основные проблемы программирования.-)
Касаемо поля "bitrate".
Насколько я понимаю, в случае lossless (по крайней мере, в случае FLAC) главное - степень сжатия в условных единицах, а битрейт не имеет большого значения, технически может оказаться каким угодно, не обязательно целым числом и не обозначает условное качество звука, которое в этом случае имеет смысл градировать по битности и частоте дискретизации исходного файла (хотя файлы большого объема трудно быстро перегонять по сети и кэшировать локально, не блокируя при этом realtime-воспроизведение, так что, скорее всего, сейчас lossless представлен исключительно по спецификации CD Audio).
А в случае lossy, наоборот, величина битрейта почти всегда фиксирована (кроме случаев VBR, переменного битрейта по ходу воспроизведения), является синонимом условного качества звука (как это было на старых не очень качественных mp3-кодеках) и по сути маскирует этот признак.
Возможно, для значений поля используют только целые числа в диапазоне из нескольких известных значений (подобно enum), а иначе ноль (хотя, опять же, логичнее было бы оставлять NULL как отсутствие значения), отбрасывая все остальное, но при таком подходе для значений FLAC можно отметить сразу 2 недостатка: неконсистентость заполнения данными (в поле с каким-то значением его то указываем, то нет, хотя стоило бы указывать всегда) и опосредованное дублирование информации (ноль по сути работает как избыточный логический флаг, обозначающий lossless FLAC, причём не по принципу истина - 1, ложь - 0, а наоборот, как exit-коды приложений в Linux). А фиксированные значения битрейта, наоборот, опосредованно обозначают собой в основном, если не полностью только lossy-записи.
Не стоит называть эти методы магическими. В них нет никакой магии, когда мы получаем результат, но не знаем, что происходит внутри в процессе его получения. Эти методы стоит называть специальными или предзаданными (predefined), т.к. они предназначены для решения конкретных задач понятным описанным в документации способом и не могут быть переопределены.
По умолчанию было бы логично, чтобы бесплатный период ожидания включался автоматически (по координатам GPS или мобильной сети), когда машина приближается на некое фиксированное расстояние до заданной при заказе точки посадки или до то самого устройства, с которого сделан заказ, если клиент перемещался уже после вызова. Иначе здесь очевидно есть слабое место с возможностью манипуляций со стороны недобросовестных водителей, сам с таким сталкивался.
С наступающим! Пусть жизнь становится лучше вместе с количеством и качеством статей. Мира, добра и новых творческих горизонтов в новом году. ?
Очевидно, "Fluent Python" Лусиану Рамальо, в русскоязычном переводе - "Python - К вершинам мастерства". Недавно как раз вышло обновлённое второе издание, из удобств, кроме прочего - в твёрдом переплёте, в отличие от первого издания.
Немного неожиданный подход к оформлению статьи. По умолчанию ожидаешь увидеть в фотографиях авторов книг, а там оказываются сотрудники, рекомендующие книги этих авторов.-)
Я слушал бобины на отцовском "Маяке" (точную модель не помню), аппаратуру высшего класса не покупал (хотя видел "Олимп", как на фото, в одной местной студии). Конечно, в тот момент, пока мода снова не возродилась, такое "железо" стоило гораздо дешевле, чем сейчас.
Ну, я родился в конце 1980-х, и на рубеже веков успел приобщиться к бобинным записям, которые делались, видимо, в первой половине 1980-х. Они у меня до сих пор хранятся. Кое-что из классики (например, первый альбом The Doors или второй альбом Dire Straits) я в первый раз услышал именно с бобины.
Собственно, строчка про Атлантиду - из одноимённой песни "Воскресения".-)
В Советском Союзе за "железным занавесом" это была целая андерграундная субкультура, которая, очевидно, ещё ждёт своих исследователей.
Люди записывали и перезаписывали альбомы любимых групп на бобины (привычные уже потом аудиокассеты пришли к нам только на рубеже 1980-х - 1990-х). При этом хорошо, если источник записи был на пластинке, взятой на время. Иначе приходилось многократно переписывать одну кассету с другой (так называемые generations, или последовательные "поколения" перезаписи), постепенно теряя в качестве звука.
Имеющиеся записи тщательно и с любовью каталогизировались в тетрадях. Каждой бобине в коллекции иногда присваивался свой порядковый номер, указывались не только выходные данные какого-то альбома, но иногда воспроизводились логотипы групп, записывались англоязычные тексты (если они имелись) и т.п.
Как пелось в одной песне, "дивный берег Атлантиды"...
Добавлю обратную связь по коду Python: лучше использовать аннотации типов, чем явно указывать в названиях параметров функции/возвращаемых значениях их тип.
Можно также упомянуть ReadyAPI от разработчиков SOAP UI, компании SmartBear. Продукт платный, но позволяет тестировать разные типы API, в последних версиях, кажется, даже GraphQL.