Стандарт на MPEG-2 Video рассматривает тот Extension не только как рекомендацию по обрезке кадра
Видимо, здесь закралась ошибка
А всё-таки здесь ffmpeg прав, вина только на пиратах.
Неважные подробности
Стандарт хочет сказать: "если Sequence Display Extension присутствует, то тогда метаданные про Display AR (4/3) начинают относиться не к размеру битмапа (720x480), а к размеру, заданному в Extension (540x480)" - если как 4/3 отображается часть кадра 540x480, то полный кадр 720x480 отображается как 16/9, всё правильно.
Но как можно пользоваться этой фичей MPEG2 Video, если из-за необязательности её поддержки ("extension ... does not define the display process", "may be ignored by decoders that conform to this specification") отношение сторон на некоторых плеерах гарантированно будет искажено? Фича подразумевает, что зрители, которым не повезло, заметят неладное и воспользуются специальной кнопкой на пульте.
Позволит хранить на 2 копии видео меньше (видео-исходник -> PNG -> JPG -> видео-результат), уменьшит количество кода. Ещё как бонус - возможность накодить в скрипте realtime-сравнение. Отдавать в плеер чередующиеся кадры до/после или модель1/модель2, с поясняющими подписями, сравнивать покадровой перемоткой туда-сюда.
Вот тут я не уверен точно. Несколькими способами я получил фактическое разрешение 640x480. Тут получается, что оба 640x480 и 720x540 нестандартные разрешения, поэтому тем более сложно понять какое оно на самом деле.
Тут непросто осознать, что из-за концепции неквадратных пикселей приходится работать с тремя величинами (SAR, PAR, DAR) вместо одной (SAR или DAR, при квадратных пикселях это одно и то же).
В растре (aka битмапе) кадра на этом DVD находятся стандартные 720x480 отсчётов и 720/480 называют SAR (Storage Aspect Ratio).
В метаданных DVD где-то прописано желаемое отношение сторон на экране (Display AR), на DVD это либо 4/3 (как тут), либо 16/9.
720x480 надо как-то растянуть, чтобы получить 4/3. Как растянуть - говорит PAR, умозрительный неквадратный пиксель битмапа, удобная такая абстракция.
4/3 в виде 640x480 или 720x540 или 1280x960 - не важно, это разрешение существует только в процессе вывода DVD на экран. Или существует в новом файле (в DVD-рипе) после избавления от легаси в виде неквадратных пикселей.
Level 2
Книжка DVD Demystified говорит, что надо учитывать четвёртую величину - оверскан. PAR по книжке считается от величины (720-16)x480.
Level 3
Но кто сказал, что такое неудобное правило соблюдали все профессионалы в ходе DVD-авторинга?
Level 4
Но кто сказал, что его важно соблюдать? Величина ошибки слишком мала.
И цвета от ошибки в BT.601/709 тоже несильно уедут, кстати. И тоже нет гарантии, что профессионалы в поздних дисках учитывали BT.601/709.
И круглые объекты в кадре могут оказаться более надёжным эталоном при поиске идеально верного отношения сторон.
Я писал: "видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps".
MPEG-2 stream on DVDs is capable of storing the 24000 ÷ 1001 frames losslessly packing them into fields in 30 30000 ÷ 1001 interlaced stream using soft telecine flags [флаги repeat_first_field и top_field_first].
Это счастливая случайность, что они оказались прописаны, причём именно так.
У древних людей помимо неквадратных пикселей была ещё одна прогрессивная технология - цвета, зависящие от разрешения видео. При отсутствии этих метаданных видео низкого разрешения декодируется из YUV в RGB по одной формуле, а если разрешение увеличить хотя бы до 720p - то уже по другой формуле (так получилось). А метаданные могут отвалиться по пути или проигнорироваться плеером.
Поэтому лучше в увеличенном видео видео придерживаться HD-коэффициентов (в метаданных их можно указывать, можно не указывать) и убеждаться (в mpv, например), что красный с зелёным не поехали. Если апскейл в RGB, то должна получиться такая цепочка:
Проблема воспроизводится без объединения VOB'ов. Это ошибка в VTS_01_1.VOB.
По запросу "copy /b" "dgindex" OR "dgmpgdec" гугл должен был дать конкретику о том, почему нельзя, но он выдаёт обратное: "заложена ли возможность бинарной склейки в стандарт - Вроде как заложена".
Не хочу сильно задерживаться на этом, это история размером с отдельную статью, и надеюсь данный случай был редким исключением, поэтому нет смысла его описывать.
Фактор №1 - криво собранный пиратами DVD. В первый VOB добавили Sequence Display Extension, а в нём прописали 540x480 как размер активной части экрана[1]. Это число примерно означает, что видео 16:9 на старый 4:3-телевизор предпочтительнее впихивать с обрезкой краёв (pan&scan), чем с чёрными полосами сверху-снизу (letterbox)[2]. То есть от полного кадра 720x480 оставлять 540x480 посередине (это 0.75 от полного кадра: 16/9 * 0.75 = 4/3). Но здесь видео не 16:9 (поэтому Sequence Display Extension не нужен) и ЭЛТ-телевизоры к компьютерам подключать перестали - компьютерые плееры могут рисовать кадр целиком, игнорируя рекомендации из Extension.
Фактор №2 - кривизна ffmpeg. Они решили творить фигню, потому что в стандарте можно найти разрешение на это. "Garbage in - garbage out, проблема не на нашей стороне". Стандарт на MPEG-2 Video рассматривает тот Extension не только как рекомендацию по обрезке кадра, но и почему-то как основу для вычисления Pixel AR (aka Sample AR)[3]. Видимо, здесь закралась ошибка. Считаем по стандарту Pixel AR через Display AR и 540x480: (4/3) / (540/480) = 32/27, затем забываем, что Display AR = 4/3 (просто потому что) и пересчитываем Display AR на основе ошибочного Pixel AR и Storage AR, получаем 32/27 * 720/480 = 16:9, смело растягиваем видео до 16:9...
В показе 29.75 fps виноват в основном ffmpeg. С первыми 4 кадрами что-то не так и он по ним, видимо, решил, что тут переменный фреймрейт (сообщать об этом и показывать точное среднее значение он не захотел). Но если опустить эту ошибку, всё равно 30/1.001 fps - это бестолковое сообщение о том, как технически хранится видео на DVD (видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps). А MediaInfo здесь не ошибается.
говорят, что разрешение видео стандартное - 720x480, но если выгружать фреймы в этом разрешении, картинка становится растянута по горизонтали
Фактор №3 - незнакомство с древними технологиями. В SD-видео использовали неквадратные пиксели (Pixel AR != 1:1), так было удобнее оцифровывать аналоговое видео (в котором тоже была неквадратность - вертикальное разрешение прибито к стандарту разложения, а горизонтальное менялось). Кадр на самом деле 720x480 (Storage AR = 720/480 = 3/2), но с вытянутыми вверх пикселями (Pixel AR = 8/9) и физически на экране он должен иметь соотношение сторон Display AR = Storage AR *Pixel AR = 3/2 * 8/9 = 4/3 = 640/480 = 720/540. Лучше оквадрачивать кадр до 720x540 вместо 640x480, чтобы 11% горизонтального разрешения не терять.
С помощью ffmpeg распаковываем фильм по кадрам в формате PNG Итоговые файлы я обычно сохраняю в JPG
Эти этапы можно пропустить с помощью фреймсервера (avisynth или питоновский vapoursynth), это стандартный способ для "видео-в-видео". ffmpeg принимает на вход скрипты этих фреймсерверов (они открывают видео, на лету обрабатывают его и отдают ffmpeg'у, он кодирует), плееры разные их тоже открывают.
Они вообще известны саундтреками под NES. Или можно сказать, своей работой с ограничениями приставки? Если железо позволяет делать безупречный жирный бас (а в остальном... мало что позволяет), то надо его делать.
Слишком банально, в этой теории нет места для сдерживания прогресса и властей.
Ещё банальнее будет, если окажется, что подход с внешней HBM-памятью выгоднее. Cerebras почему-то не выпускает уменьшенные версии (с eDRAM вместо SRAM, чтобы сохранить приличный объём памяти, например) и не выглядит однозначным победителем за счёт своей технологии - без HBM никуда, а без этого MIMD все остальные обходятся, даже китайцы. Хотя могли бы носиться как с квантовыми компьютерами.
Cerebras WSE-3, где память рядом с ядрами, с пропускной способностью на 4 порядка больше, чем у HBM в обычных ИИ-ускорителях - существует, производится. А нужна всем Nvidia.
А теперь посчитайте в какую стоимость Вам обойдется RAID (да даже просто стопка HDD) такого объема.
Да во столько и обойдётся, только проблем меньше будет.
Это рекламные ёмкости со сжатием, реальные в 2.5 раза меньше - 12/"30" ТБ и 18/"45" ТБ.
Новый привод стоит как недорогой автомобиль, поэтому для дома можно рассчитывать лишь на б/у LTO примерно 6 поколения (под кассеты на 2.5 ТБ), а кассеты там подороже и ответное рассмотрение б/у жёстких дисков опускает цену терабайта до уровня ленты. Но добавляется экономия на приводе, SAS/FC HBA, чистой комнате, контролируемой температуре и влажности, исчезает такая единая точка отказа как привод и снижаются риски, потому что сообщество существует и делится информацией. Либо эта экономия заменяется на повышение надёжности (больше избыточности, менее сомнительные диски).
К ленте для окупаемости стоит добавить либо желание поиграться (оно точно окупится), либо петабайт данных (чтобы размазать по нему стоимость новых приводов), либо аренду привода.
Какой смысл вешать в воздухе всю сборку вместе с двигателем?
Развязать от пола и встроенных колонок понизить себестоимость. Какой смысл этого не делать? Покупатели выйдут на митинг с плакатами "Audio-Technica держит вас за дураков" и навредят продажам? Да ни в жизнь.
Не знаю, что в нём лучшего, но... если коробка квадратная, то в ней что-то круглое там, где дуб, там и ависинт. Где ависинт, там редактор к нему - AvsPmod. А он поддерживает Linux. Если с ним окажется что-то не так (особенно на линуксе), то и неудивительно, это всё устаревает примерно как дуб и заменяется VapourSynth'ом, к которому так и не создали хороший редактор (тем более, что как дуб возродился в виде дуба2, так и ависинт возродили в виде AviSynth+), но который в какой-то степени совместим с AvsPmod.
Есть ли что-то подобное для Linux?
Так вот. Не знаю, что в нём лучшего, но вся эта мешанина очень подобна друг-другу и совместима. Старый редактор AvsPmod открывает новые скрипты VapourSynth, который открывает плагины AviSynth, которые импортируют плагины VirtualDub...
А он же, но с наклейкой "LG GoldStar" - уже $350 (VCP-4100M). Но тоже самый дешёвый из линейки производителя в каталоге, за следующую модель с записью хотят в 1.5-2 раза больше.
А, нет, в английском тоже плеер может быть пишущим, на Orson OV202RN так написано. Но тот, что за $200 в каталоге помечен как "Realistic Model 10 - Videocassette player without recording capability".
Ну, в каталоге нет наших терминологических химер, там однозначные Video Cassette Recorder либо Player и дополнительная пометка, что на функции записи сэкономили.
Что такое "нормальная пауза"?
Вчера же спрашивали...
Да, платить стало удобней, чем пиратить.
На второй круг заходим. Мой взгляд был: стало удобнее, потому что пиратство сделали неудобнее, пиратов прижали. А если возможность остаётся, то прекрасно пиратят (=>Nintendo).
нужны - но не за ту разницу в цене, что LD предлагал.
Вот вы всё меньше говорите про удобство и всё больше говорите про цену. Прямо как я в первом комменте предлагал =)
За нарушение ИП, а не за эмуляцию.
Это как шутка про Linux ISO's, только про "запуск в эмуляторе своих легальных бэкапов"? Все всё понимают.
for “facilitating piracy at a colossal scale” - Verge
Цены на VHS-проигрыватели в 90 году начинались где-то от сотни, а самый дешевый LD стоил 300-400$.
Соотношение цен 3x к VHS-проигрывателям и 2x к VHS-видеомагнитофонам и правда гуглится[*].
Цены на VHS-проигрыватели
Вот вместо слов про удобство функции записи пошли цены других устройств, без записи. И нормальная пауза уже не нужна, и перемотка по времени, и главы. Я ж говорю - народу надо дешевле, а пауза на переворачивание - это 100% ерунда, вон вы как цитату про паузы рекламные оборвали.
Успехи в борьбе с пиратством достигаются удобными способами доступа к контенту и его оплате. Как только стим стал удобен - люди пошли туда.
А куда ж они денутся, если Denuvo не ломается? У вас какой-то идеализм, в реальности:
пока пиратить можно, говорят "мы бы платили, да неудобно"
когда возможность пропадает - "не очень-то и хотелось, платить удобно стало"
эмуляторы Nintendo в вашу концепцию не вписываются, поэтому для вас - "гиковское развлечение", а для Nintendo $2.4 миллиона с разработчиков Yuzu. Пиратство на самом Switch - тоже не уникальное геотемпоральное явление, вызванное неудобством оплаты.
_________
[*]
В одном большом каталоге были от $200 видаки без функции записи, от $250 - с записью, от $400 - с Hi-Fi Stereo и это в 3 - 2 - 1.5 раза дешевле LD-проигрывателя за $550 (самого дешёвого там, но не без поддержки CAV-дисков и цифрозвука).
Делать было нечего...
Моделей там 7 штук против ~250, продажи фильмов на кассетах/LD соотносятся примерно так же.
В Billboard в 1992 пишут, что один фиг LD брать не будут - или они становятся не дороже VHS и массово появляются в видеопрокате, или вот так. Не "чтобы не требовалось переворачивать", а "чтобы не дороже кассет", смотрите. А на халяву так и уксус сладкий.
В 1995 пишут, что Pioneer обновил свой рекорд - выпустил модель за $300, есть поддержка CD.
А всё-таки здесь ffmpeg прав, вина только на пиратах.
Неважные подробности
Стандарт хочет сказать: "если Sequence Display Extension присутствует, то тогда метаданные про Display AR (4/3) начинают относиться не к размеру битмапа (720x480), а к размеру, заданному в Extension (540x480)" - если как 4/3 отображается часть кадра 540x480, то полный кадр 720x480 отображается как 16/9, всё правильно.
Но как можно пользоваться этой фичей MPEG2 Video, если из-за необязательности её поддержки ("extension ... does not define the display process", "may be ignored by decoders that conform to this specification") отношение сторон на некоторых плеерах гарантированно будет искажено? Фича подразумевает, что зрители, которым не повезло, заметят неладное и воспользуются специальной кнопкой на пульте.
Позволит хранить на 2 копии видео меньше (видео-исходник ->
PNG->JPG-> видео-результат), уменьшит количество кода. Ещё как бонус - возможность накодить в скрипте realtime-сравнение. Отдавать в плеер чередующиеся кадры до/после или модель1/модель2, с поясняющими подписями, сравнивать покадровой перемоткой туда-сюда.Тут непросто осознать, что из-за концепции неквадратных пикселей приходится работать с тремя величинами (SAR, PAR, DAR) вместо одной (SAR или DAR, при квадратных пикселях это одно и то же).
В растре (aka битмапе) кадра на этом DVD находятся стандартные 720x480 отсчётов и 720/480 называют SAR (Storage Aspect Ratio).
В метаданных DVD где-то прописано желаемое отношение сторон на экране (Display AR), на DVD это либо 4/3 (как тут), либо 16/9.
720x480 надо как-то растянуть, чтобы получить 4/3. Как растянуть - говорит PAR, умозрительный неквадратный пиксель битмапа, удобная такая абстракция.
4/3 в виде 640x480 или 720x540 или 1280x960 - не важно, это разрешение существует только в процессе вывода DVD на экран. Или существует в новом файле (в DVD-рипе) после избавления от легаси в виде неквадратных пикселей.
Level 2
Книжка DVD Demystified говорит, что надо учитывать четвёртую величину - оверскан. PAR по книжке считается от величины (720-16)x480.
Level 3
Но кто сказал, что такое неудобное правило соблюдали все профессионалы в ходе DVD-авторинга?
Level 4
Но кто сказал, что его важно соблюдать? Величина ошибки слишком мала.
И цвета от ошибки в BT.601/709 тоже несильно уедут, кстати. И тоже нет гарантии, что профессионалы в поздних дисках учитывали BT.601/709.
И круглые объекты в кадре могут оказаться более надёжным эталоном при поиске идеально верного отношения сторон.
Я писал: "видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps".
Вот википедия аккуратно слова подбирает:
MPEG-2 stream on DVDs is capable of storing the 24000 ÷ 1001 frames losslessly packing them into fields in
3030000 ÷ 1001 interlaced stream using soft telecine flags [флаги repeat_first_field и top_field_first].*Про piraty_fragment_hd.mkv на гуглодиске*
MediaInfo:
Matrix coefficients : BT.470 System B/GЭто счастливая случайность, что они оказались прописаны, причём именно так.
У древних людей помимо неквадратных пикселей была ещё одна прогрессивная технология - цвета, зависящие от разрешения видео. При отсутствии этих метаданных видео низкого разрешения декодируется из YUV в RGB по одной формуле, а если разрешение увеличить хотя бы до 720p - то уже по другой формуле (так получилось). А метаданные могут отвалиться по пути или проигнорироваться плеером.
Поэтому лучше в увеличенном видео видео придерживаться HD-коэффициентов (в метаданных их можно указывать, можно не указывать) и убеждаться (в mpv, например), что красный с зелёным не поехали. Если апскейл в RGB, то должна получиться такая цепочка:
[YUV] ---по-BT.601---> [RGB] ---апскейл---> [RGB] ---по-BT.709---> [YUV]Скрытый текст
Проблема воспроизводится без объединения VOB'ов. Это ошибка в VTS_01_1.VOB.
По запросу "copy /b" "dgindex" OR "dgmpgdec" гугл должен был дать конкретику о том, почему нельзя, но он выдаёт обратное: "заложена ли возможность бинарной склейки в стандарт - Вроде как заложена".
Говорят, что нельзя, но примеры поломок не приводят. Ниже написал, из-за чего тут на самом деле проблема (она в первом VOB'е).
*для тех, кто тоже распарсил не с первого раза*
...заметно лучше, чем 1080p с недостаточным битрейтом (как на ютубе).
Фактор №1 - криво собранный пиратами DVD. В первый VOB добавили Sequence Display Extension, а в нём прописали 540x480 как размер активной части экрана[1]. Это число примерно означает, что видео 16:9 на старый 4:3-телевизор предпочтительнее впихивать с обрезкой краёв (pan&scan), чем с чёрными полосами сверху-снизу (letterbox)[2]. То есть от полного кадра 720x480 оставлять 540x480 посередине (это 0.75 от полного кадра: 16/9 * 0.75 = 4/3). Но здесь видео не 16:9 (поэтому Sequence Display Extension не нужен) и ЭЛТ-телевизоры к компьютерам подключать перестали - компьютерые плееры могут рисовать кадр целиком, игнорируя рекомендации из Extension.
Фактор №2 - кривизна ffmpeg. Они решили творить фигню, потому что в стандарте можно найти разрешение на это. "Garbage in - garbage out, проблема не на нашей стороне". Стандарт на MPEG-2 Video рассматривает тот Extension не только как рекомендацию по обрезке кадра, но и почему-то как основу для вычисления Pixel AR (aka Sample AR)[3]. Видимо, здесь закралась ошибка. Считаем по стандарту Pixel AR через Display AR и 540x480: (4/3) / (540/480) = 32/27, затем забываем, что Display AR = 4/3 (просто потому что) и пересчитываем Display AR на основе ошибочного Pixel AR и Storage AR, получаем 32/27 * 720/480 = 16:9, смело растягиваем видео до 16:9...
В показе 29.75 fps виноват в основном ffmpeg. С первыми 4 кадрами что-то не так и он по ним, видимо, решил, что тут переменный фреймрейт (сообщать об этом и показывать точное среднее значение он не захотел). Но если опустить эту ошибку, всё равно 30/1.001 fps - это бестолковое сообщение о том, как технически хранится видео на DVD (видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps). А MediaInfo здесь не ошибается.
Фактор №3 - незнакомство с древними технологиями. В SD-видео использовали неквадратные пиксели (Pixel AR != 1:1), так было удобнее оцифровывать аналоговое видео (в котором тоже была неквадратность - вертикальное разрешение прибито к стандарту разложения, а горизонтальное менялось). Кадр на самом деле 720x480 (Storage AR = 720/480 = 3/2), но с вытянутыми вверх пикселями (Pixel AR = 8/9) и физически на экране он должен иметь соотношение сторон Display AR = Storage AR * Pixel AR = 3/2 * 8/9 = 4/3 = 640/480 = 720/540. Лучше оквадрачивать кадр до 720x540 вместо 640x480, чтобы 11% горизонтального разрешения не терять.
Эти этапы можно пропустить с помощью фреймсервера (avisynth или питоновский vapoursynth), это стандартный способ для "видео-в-видео". ffmpeg принимает на вход скрипты этих фреймсерверов (они открывают видео, на лету обрабатывают его и отдают ffmpeg'у, он кодирует), плееры разные их тоже открывают.
Нейронки я в них не пробовал, но какие-то плагины есть:
https://github.com/Asd-g/avs-mlrt/blob/main/mlrt_ort/README.md
https://github.com/rlaphoenix/VSGAN/blob/master/vsgan/networks/swinir.py
https://github.com/HolyWu/vs-swinir
DVD в фреймсерверах правильнее всего открывать с помощью плагина D2V Source:
https://github.com/Asd-g/MPEG2DecPlus (avisynth)
https://github.com/dwbuiten/d2vsource (vapoursynth)
Он открывает файлы-индексы-для-группы-VOB'ов - .d2v, создаваемые через DGIndex (ещё какой-то D2V Witch есть): https://www.rationalqm.us/dgmpgdec/dgmpgdec.html
Индексация сторонней утилитой добавляет неудобства, но зато даёт надёжный случайный доступ и доп. информацию про DVD (в DGIndex: Tools -> Parse D2V).
Проблема с 29.97 fps у заведомо прогрессивного видео в DGIndex решается через Video -> Field Operation -> Forced Film перед созданием .d2v.
[1] Такое может показать этот софт: https://www.headbands.com/gspot/
[2] https://www.ee.columbia.edu/~eleft/e6880-Spring97/docs/is138182.pdf#page=68 ("display_horizontal_size and display_vertical_size together define...")
[3] https://www.ee.columbia.edu/~eleft/e6880-Spring97/docs/is138182.pdf#page=60 (формула отличается, потому что в стандарте SAR и DAR определены перевёрнутыми, чтобы было не скучно: 9:16, 3:4...; то есть там SAR = DAR x ... = 1/Non-Inverted-Pixel-aka-Sample-AR = 1/Non-Inverted-Display-AR x ...)
*продолжая оффтоп про NES*
Они вообще известны саундтреками под NES. Или можно сказать, своей работой с ограничениями приставки? Если железо позволяет делать безупречный жирный бас (а в остальном... мало что позволяет), то надо его делать.
Ещё 3 трека
Слишком банально, в этой теории нет места для сдерживания прогресса и властей.
Ещё банальнее будет, если окажется, что подход с внешней HBM-памятью выгоднее. Cerebras почему-то не выпускает уменьшенные версии (с eDRAM вместо SRAM, чтобы сохранить приличный объём памяти, например) и не выглядит однозначным победителем за счёт своей технологии - без HBM никуда, а без этого MIMD все остальные обходятся, даже китайцы. Хотя могли бы носиться как с квантовыми компьютерами.
Власти скрывают. Скрывают, что они скрывают.
Cerebras WSE-3, где память рядом с ядрами, с пропускной способностью на 4 порядка больше, чем у HBM в обычных ИИ-ускорителях - существует, производится. А нужна всем Nvidia.
Да во столько и обойдётся, только проблем меньше будет.
Это рекламные ёмкости со сжатием, реальные в 2.5 раза меньше - 12/"30" ТБ и 18/"45" ТБ.
Новый привод стоит как недорогой автомобиль, поэтому для дома можно рассчитывать лишь на б/у LTO примерно 6 поколения (под кассеты на 2.5 ТБ), а кассеты там подороже и ответное рассмотрение б/у жёстких дисков опускает цену терабайта до уровня ленты. Но добавляется экономия на приводе, SAS/FC HBA, чистой комнате, контролируемой температуре и влажности, исчезает такая единая точка отказа как привод и снижаются риски, потому что сообщество существует и делится информацией. Либо эта экономия заменяется на повышение надёжности (больше избыточности, менее сомнительные диски).
К ленте для окупаемости стоит добавить либо желание поиграться (оно точно окупится), либо петабайт данных (чтобы размазать по нему стоимость новых приводов), либо аренду привода.
Развязать от пола и встроенных колонокпонизить себестоимость. Какой смысл этого не делать? Покупатели выйдут на митинг с плакатами "Audio-Technica держит вас за дураков" и навредят продажам? Да ни в жизнь.Всем бы так о продажах на десять миллионов долларов говорить.
Но штука смешная. Встроенные колонки, ременной привод. Со стабильностью не должно быть проблем - левитирует проигрыватель, он не вращается.
70-90 кВт-ч в месяц, то есть.
А их сотня ватт - это как потребление массива жёстких дисков на 250-500 терабайт, при несравнимо худшей сохранности данных.
Скрытый текст
Не знаю, что в нём лучшего, но...
если коробка квадратная, то в ней что-то круглоетам, где дуб, там и ависинт. Где ависинт, там редактор к нему - AvsPmod. А он поддерживает Linux. Если с ним окажется что-то не так (особенно на линуксе), то и неудивительно, это всё устаревает примерно как дуб и заменяется VapourSynth'ом, к которому так и не создали хороший редактор (тем более, что как дуб возродился в виде дуба2, так и ависинт возродили в виде AviSynth+), но который в какой-то степени совместим с AvsPmod.Так вот. Не знаю, что в нём лучшего, но вся эта мешанина очень подобна друг-другу и совместима. Старый редактор AvsPmod открывает новые скрипты VapourSynth, который открывает плагины AviSynth, которые импортируют плагины VirtualDub...
https://github.com/gispos/AvsPmod
А он же, но с наклейкой "
LGGoldStar" - уже $350 (VCP-4100M). Но тоже самый дешёвый из линейки производителя в каталоге, за следующую модель с записью хотят в 1.5-2 раза больше.Это "не уникальное геотемпоральное явление, вызванное неудобством оплаты" - т.е. её пиратят не только в России и не только после 2022.
Если его не существует, то ситуация сильно упрощается. Так и после появления денувы ситуация с пиратством стала проще описываться.
А, нет, в английском тоже плеер может быть пишущим, на Orson OV202RN так написано. Но тот, что за $200 в каталоге помечен как "Realistic Model 10 - Videocassette player without recording capability".
Ну, в каталоге нет наших терминологических химер, там однозначные Video Cassette Recorder либо Player и дополнительная пометка, что на функции записи сэкономили.
Вчера же спрашивали...
На второй круг заходим. Мой взгляд был: стало удобнее, потому что пиратство сделали неудобнее, пиратов прижали. А если возможность остаётся, то прекрасно пиратят (=>Nintendo).
Вот вы всё меньше говорите про удобство и всё больше говорите про цену. Прямо как я в первом комменте предлагал =)
Это как шутка про Linux ISO's, только про "запуск в эмуляторе своих легальных бэкапов"? Все всё понимают.
for “facilitating piracy at a colossal scale” - Verge
Соотношение цен 3x к VHS-проигрывателям и 2x к VHS-видеомагнитофонам и правда гуглится[*].
Вот вместо слов про удобство функции записи пошли цены других устройств, без записи. И нормальная пауза уже не нужна, и перемотка по времени, и главы. Я ж говорю - народу надо дешевле, а пауза на переворачивание - это 100% ерунда, вон вы как цитату про паузы рекламные оборвали.
А куда ж они денутся, если Denuvo не ломается? У вас какой-то идеализм, в реальности:
пока пиратить можно, говорят "мы бы платили, да неудобно"
когда возможность пропадает - "не очень-то и хотелось, платить удобно стало"
эмуляторы Nintendo в вашу концепцию не вписываются, поэтому для вас - "гиковское развлечение", а для Nintendo $2.4 миллиона с разработчиков Yuzu. Пиратство на самом Switch - тоже не уникальное геотемпоральное явление, вызванное неудобством оплаты.
_________
[*]
В одном большом каталоге были от $200 видаки без функции записи, от $250 - с записью, от $400 - с Hi-Fi Stereo и это в 3 - 2 - 1.5 раза дешевле LD-проигрывателя за $550 (самого дешёвого там, но не без поддержки CAV-дисков и цифрозвука).
Моделей там 7 штук против ~250, продажи фильмов на кассетах/LD соотносятся примерно так же.
В Billboard в 1992 пишут, что один фиг LD брать не будут - или они становятся не дороже VHS и массово появляются в видеопрокате, или вот так. Не "чтобы не требовалось переворачивать", а "чтобы не дороже кассет", смотрите.
А на халяву так и уксус сладкий.В 1995 пишут, что Pioneer обновил свой рекорд - выпустил модель за $300, есть поддержка CD.