mayton2019

Мне видится такая декомпозиция.
1) перевод источника (mp3/aac/ogg) в формат pcm.
2) распознавание ритма и основной мелодии и гармонии. Выделение отдельных инструментов и классификация.
3) рендеринг ударной партии и сведение сольных партий с дистошеном.
4) pcm -> mp3

Пункт 2 является самым сложным. За него даже заплатят денег если автор осилит это.

Остальные пункты этого задания технически решены и интереса не представляют. Они - утилитарны.

Схема при которой пользователь вводит НЕЧТО с клавиатуры и это нечто расматривается как ключ шифрования - очень слабая схема и не выдерживает атак. Пользоватль ленив и глуп. И всегда будет стараться вводить пароли и ключи по 1-2 символа. С этим ничего не поделать. Поэтому если автор заинтересован чтобы поле ключей было более сложным - надо использовать во первых SALT в совокупности с паролем. И использовать функцию хеширования наподобие SHA1 чтобы получить более-менее сложый ключ. В некоторых случаях (сеансовые ключи) можно получить энтропию из внешнего мира (часы в микросекундах и текущее положение мышки на экрасне).

Тоесть само наличие в схеме алгоритма RC5 еще не гарантирует что у тебя система надежна. Нужно чтобы ее использование было чистым и лишенным человеческого фактора.

Это очень стандартная задача для теории алгоритмов. Погугли "задача о разбиении числа". Она решалась очень много раз и есть для всех языков.

В топике КМК спутаны несколько вопросов. Сжатие и кроп - это разные методы. И crop теоретически
повреждает картинку убирая из нее потенциально значимую часть сведений (копирайты или
надписи внизу). Поэтому надо обговорить твоё задание не с бухты-барахты а более детально.

Что делает imagecompressor - я не знаю. Но предположительно он берет JPEG и прогоняет по нему WEBP
алгоритмы и потом перегоняет обратно в JPEG используя некую совместимость между ними. В цифру
70 % я не поверю. Там скорее всего идет какой-то нечеткий критерий. А в условиях нечеткости можно написать
любые проценты и при этом окружающие покивают головами ведь критерий-то нечеткий.

По поводу сервиса. Я-бы поднял AWS-Lambda и поставил туда какой-то опенсорцный JPEG-WEBP кодек
и использовал бы для себя как конвертер. Но по последнему пункту тебе надо искать программиста
под AWS.

Они так и называются SHA1 - Secure Hash Algorithm 1, MD5 - Message Digest 5.

Тебе по сути надо 300 файлов разложить на 2 кучки. SQL и не-SQL верно?

Автор у тебя уже есть какой-то HelloWorld для 8086 где есть каркас этого приложения?

Опубликуй пожалуйста. Я думаю что это будет очень продуктивно иначе участники топика не поймут что именно тебе непонятно.

Непонятно что такое "хост" и как с него можно что-то собирать. Хост - это технический термин. Не бизнесовый и наверное в топике имелось в виду другое. Может на этих хостах - ftp/cifs файловые хранилища?

Правильно выше пишут. Технически tar+cron решает эту задачу. И обычно самое простое решение - самое надежное. Если "хочется отслеживать" - то это уже другая задача. И она не имеет прямого отношения к бэкапу. Тоесть вопрос состоит из двух независимых частей. Собственно бэкап. И какой-то мониторинг который должен ... что то мониторить.

Да. Если ты сохраняешь в JPEG то он тебе подкинет свинью. Тк работает не с дискретным а с непрерывным (синусно-косинусным) представлением маленьких фрагментов картинки.

Реально тебе нужна гарантия что destination будет всегда в форматах GIF/PNG т.к только они гарантируют точное соотвествие цвета на входе и на выходе.

В задании есть какое-то противоречие. Внутри одной папки могут лежать файлы по разным месяцам. Что делать в таком случае - непонятно. Вобщем автору надо детализировать задание чтоб отвечающие могли понять что на самом деле надо. Что должно быть на выходе.

Можно корркетировать не только вектор скорости но и координату. Это спасёт шарик от сингулярностей.

if(x + 64 > 320.0) {
  dx = -dx;
  x = 320.0;
} else if (x < 0.0) {
  dx = -dx;
  x = 0.0;
}

if (y ... e.t.c.

Непонятно что ты собрался сделать здесь внутри. Если загрузить гигабайтный файл в один текст-контрол то конечно не получится. Контролы для этого не предназначены. Они не хранят гигабайты потому-что память дорого стоит для приложения.

FileReader reader = new FileReader("table.txt");
            BufferedReader br = new BufferedReader(reader);
            //jTextArea1.read(br, null);
            //jTextArea1.requestFocus();
            br.close();

Ошибка скорее всего в постановке задачи. Поставь задачу словесно. Что надо сделать. Может не надо отображать весь файл а только его хвостовую часть (последние 50 строк).

Предположительно - есть поскольку вы используете NewByteArray но не используете DeleteLocalRef.

Это называется генерация перестановок.

Полоски не помешают нейронной сети узнать символы. Не отвлекайтесь на ерунду.

Можно пойти в универ и найти там голодных студентов готовых к тому чтоб подзаработать. Единственное - надо потребовать что-б они после финала разработки предоставили все сорцы и доказательство того что код был собран на этих сорцах. Ну и какая-то минимальная документация. Это для старта.

А дальше - как пойдет.