Метаданные все равно остаются. Это тоже может быть непонятно.
JFIF в начале - это комментарий, там может быть что угодно. У вас 3-й байт 0xFF относится уже к следующему маркеру. Парсер пропускает все от данных (структрура которых задается маркером) до следующего маркера. У начального маркера данных нет, поэтому файл может начинаться например как 0xFF, 0xD8, "Hello world", 0xFF, 0xDB.
Насчет исключения да, спасибо, надо поправить. Но судя по тому, что вы сохранили как txt, замечу, что это не рендерер img->ascii. Более наглядно получается, если в исходном изображении нет мелких деталей.
Мне кажется, что финальная версия функция рисования противоречит Single Responsible Principle. Здесь и сортировка и отрисовка. Хотя порядок определяется не в этой функции, но, тем не менее, он завязан на operator<, что не очень гибко. Например, нам может понадобится распечатывать объекты с другим порядком, тогда нужно передавать предикат. Лучше передавать в функцию уже упорядоченный список.
Спасибо! :)
Редактирования чего? Текст, начало и конец редактируются в любое время. Пока нельзя изменить уровень (например начать изучение сначала, если никак не запоминается, или наоборот, если слишком легко идет).
Сейчас я использую VLC API. Если у других плееров есть API, то теоретически можно реализовать переключение между ними. Правда я не нашел таких, кроме ffmpeg.
Не уверен, что с помощью плагина можно реализовать нужный UX.
Если вы интересуетесь самой методологией как лучше повторять, то я не берусь советовать, так как не компетентен в этом. При разработке читал про различные подходы, ну и руководствовался собственным представлением.
Если же говорить о практическом использовании приложения, то не так уж важно как именно разбивать. Все по настроению. Добавление клипа не засчитывается за повторение, поэтому первое повторение можно отложить надолго. То есть можно потратить неделю на просмотр фильма, добавить 200 клипов, а потом разгребать их понемногу. Я предпочитаю не добавлять более 20 в день, так как нужно будет много повторять.
При разработке я хотел сделать максимально дружелюбное приложение, которое не обязывает пользователя что-то делать, а лишь направляет. Отсюда и этимология названия — (обычный) плеер, но с возможностью повторения. Пользователь сам решает, что он хочет повторять, что не хочет, когда хочет.
К сожалению, таких возможностей пока нет. Реализовать выбор аудио-дорожки, думаю, нетрудно, но что-то не нашел механизмов извлечения субтитров в libVLC. А вообще меня обосрали за такой подход (не на Хабре), и хоть какой-то фидбек по приложению я получил только от вас, то не планирую развивать приложение. Сейчас оно вполне удовлетворяет мои нужды.
Если повторять регулярно, то уровень будет примерно равен количеству повторений. Уровень задает интервал следующего повторения. Суть такая, что чем выше уровень, тем реже приходится повторять, клип как бы «прокачивается». Насчет того как правильно повторять написано много научных статей, у меня же простая экспоненциальный метод, который оптимален для меня. Но приложение еще в разработке, поэтому можно добавить какой-нибудь коэффициент в настройках. Сейчас нужно периодически (в идеале раз в 1-2 дня) и повторять «созревшие» клипы.
Спасибо за идеи! Первый вариант, действительно, запутанный. Второй интереснее. Нужно только подумать, хранить ли файлы в clips_dir единой кучей или повторять структуру video_dir. Пожалуй, второй случай лучше, так как в первом могут произойти коллизии имен. Правда теряется возможность открытия произвольного каталога.
Logseq. Десктопный (правда на Электроне), self-hosted, опенсорсный.
jpeg не изменился и все так же популярен :) Рад, что пригодилось!
Метаданные все равно остаются. Это тоже может быть непонятно.
JFIF в начале - это комментарий, там может быть что угодно. У вас 3-й байт 0xFF относится уже к следующему маркеру. Парсер пропускает все от данных (структрура которых задается маркером) до следующего маркера. У начального маркера данных нет, поэтому файл может начинаться например как 0xFF, 0xD8, "Hello world", 0xFF, 0xDB.
Вы ещё один, который подумал, что я сделал рендерер в ascii. Одни и те же символы предназначены и для визуализации и для декодера
А, у меня была старая версия Хабра, в ней все норм. Спасибо, добавил примечание!
Я с питоном не очень знаком. Спасибо, попробую )
Насчет исключения да, спасибо, надо поправить. Но судя по тому, что вы сохранили как txt, замечу, что это не рендерер img->ascii. Более наглядно получается, если в исходном изображении нет мелких деталей.
Мне кажется, что финальная версия функция рисования противоречит Single Responsible Principle. Здесь и сортировка и отрисовка. Хотя порядок определяется не в этой функции, но, тем не менее, он завязан на operator<, что не очень гибко. Например, нам может понадобится распечатывать объекты с другим порядком, тогда нужно передавать предикат. Лучше передавать в функцию уже упорядоченный список.
Про некоммерческий проект можно написать и в технические хабы, так про него узнает больше.
Редактирования чего? Текст, начало и конец редактируются в любое время. Пока нельзя изменить уровень (например начать изучение сначала, если никак не запоминается, или наоборот, если слишком легко идет).
Сейчас я использую VLC API. Если у других плееров есть API, то теоретически можно реализовать переключение между ними. Правда я не нашел таких, кроме ffmpeg.
Не уверен, что с помощью плагина можно реализовать нужный UX.
Если же говорить о практическом использовании приложения, то не так уж важно как именно разбивать. Все по настроению. Добавление клипа не засчитывается за повторение, поэтому первое повторение можно отложить надолго. То есть можно потратить неделю на просмотр фильма, добавить 200 клипов, а потом разгребать их понемногу. Я предпочитаю не добавлять более 20 в день, так как нужно будет много повторять.
При разработке я хотел сделать максимально дружелюбное приложение, которое не обязывает пользователя что-то делать, а лишь направляет. Отсюда и этимология названия — (обычный) плеер, но с возможностью повторения. Пользователь сам решает, что он хочет повторять, что не хочет, когда хочет.