Ычан: [d | au / b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
Имя
Animapcha image [@] [?]
Тема   (новая нить)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5000 кБ.
  • Ныне 3540 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
No. 7468       [Ответ]
Решил для мультиплеера использовать jabber.
вроде как это пошлёт месагу:
<message xmlns='jabber:client' from='juliet@example.com/balcony' to='romeo@example.net' type='chat'> <body>What's up?</body> </message>

У меня вопросы:
1) как авторизоваться?
2) как закрыть сессию?
3) как посылать и обрабатывать сообщения присутствия?
4) Как принять сообщение?
39 сообщений и 19 изображений пропущено. Для просмотра нажмите «Ответ».
No. 7567  
>>7565
> phpшники не программисты. Навидался я на них.
Чиочую.
Похапешник - это дизайнер, проектировщик баз данных, проектировщик интерфейсов - кто угодно, но не программист.
No. 25488  
???? ????? ?????.jpg - (43.14KB, 1420×2200)
25488
Можно я тут потестирую кое-что? С сажей тред не должен подняться. Спасибо
No. 26485  
>>7520
10 лет посту!
No. 26489  
>>26485
А джаббер еще жив!
No. 26500  
>>26485
Я-то думаю чего доска такая живая вдруг. Не написал ОП свой космосимулятор...
No. 26501  
>>26500
Просто за него хардкорный космосимулятор написали в Мексике.
No. 26512  
>>26500
Возможно, он осилил и перешел на высший уровень бытия. И ему уже не до нас, в солнечной Калифорнии.
kotoba_logo_lg.png - (51.07KB, 349×500)
18881
No. 18881       [Ответ] [Первые 100 сообщений] [Последние 50 сообщений]
DISCLAIMER: Данный проект не является форком kotoba-ib и его разработка не ведется персоналом «Супермаркета».

Этот тред посвящен разработке очередного движка имиджборды под названием «kotoba.js». Движок написан на NodeJS, в качестве базы данных MongoDB, стек express, mongoose, passport.js является сегодня настолько же стандартным, как PHP в свое время. Фронтенд использует Sass и Babel, его сборка автоматизирована (gulp+babelify, но со временем нужно перейти на Webpack). Верстка - полностью валидный HTML5, однако максимально напоминает Вакабу, что позволяет работать стороннему коду (Кукле и мобильным клиентам) без существенных доработок. Так же движок работает по классическому принципу генерирования статичных файлов и имеет схожую структуру каталогов.

Несмотря на наличие современных движков, некоторые их которых даже используют похожий стек (такие как LynxChan и ololord.js), до сих пор тут и там регулярно появляются вопросы по установке морально устаревших Вакабы, Кусабы, Вичана и их форков. При этом установка и обслуживание таких движков крайне затруднительна в виду почти полного отсутствия документации, устаревших зависимостей, и необходимости доработки движка, добавления недостающих функций, и исправления устаревшей верстки.

Целью данного проекта является создание движка с классическим дизайном и привычным для современных борд функционалом, отличающийся максимальной простотой в установке. Достигается это за счет конейнеризации приложения с помощью Docker.

Как выглядит процесс установки типичного движка на локалхост:

  • Установить Apache, PHP, MySQL
  • Убедиться что PHP скомпилирован с нужными флагами и что установлена нужная версия интерпретатора (PHP 5.6 будет ругаться на то, что работало в PHP 5.4)
  • Установить ImageMagic и ffmpeg для поддержки webm
  • Править config.php, проводить манипуляции с install.php (который никогда не выполняется первого раза без ошибок)
Так выглядит установка котобы:

  • Установить docker и docker-compose (дело 1 минуты)
  • Скачать исходный код из репозитория
  • Выполнить docker-compose up -d в папке с кодом.
Установка всех зав
Сообщение слишком длинное. Полный текст.
182 сообщений и 57 изображений пропущено. Для просмотра нажмите «Ответ».
No. 22478  
image.png - (105.06KB, 247×315)
22478
Извиняюся, но у меня кнопочка "quick reply" не вставляет ссылку на пост в месседж бокс. И еще когда наводишь мышку на реплаи, то всплывает красненькое окошечко с надписью "500 internal server error".
Что-то криво поставилося?
No. 22479  
image.png - (26.44KB, 789×280)
22479
>>22478
Так же кнопочки "удалить, закрепить, закрыть, открыть" тоже выдает ошибку 500.
Еще кнопочка stuff выдает пик.
No. 22591  
079Slowpoke.png - (387.86KB, 844×844)
22591
>>22478>>22479
Спасибо за багрепорт. Все исправлено (некоторое время назад).
Страница Staff выдавала ошибку из-за того, что не было добавлено ни одной роли (manage/roles), и вместо пустого массива у юзера роли были undefined. По той же причине не работали попапы. Теперь работает и без ролей.
Быстрого ответа просто не было запилено, теперь он есть.
No. 22636  
image.png - (5.66KB, 268×126)
22636
>>22591
Спасибо!
Но теперь оно постить отказывается :3
No. 22641  
>>22636
Еще одна тупая ошибка, которая проявляется только на пустой доске. Исправлено.
Добавлена новая фича - редактор стилей. Дополнительные темы можно клепать прямо через админку.
Так же обновлен node.js и все остальное. Контейнеры необходимо пересобрать командой -d --force-recreate --build
No. 22642  
>>22641
> docker-compose up -d --force-recreate --build
fix
No. 26300  
GJ
250px-SHODAN_hires.jpg - (31.47KB, 250×268)
20392
No. 20392       [Ответ]
tcp://breathe.network:31337 (plaintext)
No. 20400  
>>20392
Чего ещё расскажешь?
No. 20406  
Запилено:
  • Двухступенчатая архитектура, из брокера подключений и бекенда, реализующего логику.
  • Подключение по ssh, после /регистрации своего ssh-ключа в плейнтекстовой моде
  • Персистентность, история, мемосерв.

No. 26166  
Вот уже пять дней у меня работает tmux с запущенным в нём
nc breathe.network 31337
. Чат пустует и на мои сообщения никто не отвечает. Команда
/list
возвращает
 def#1348 -- 2022-05-15 11:21:4

No. 26032       [Ответ]
Добрый вечер!

Только начал знакомиться с программированием и знаю лишь основы C++ и C#. Хочу попробовать сделать свою игру на ПК, что-то по типу визуальной новеллы (БЛ, DDLC, etc). На каком языке/движке лучше в 2к22 делать подобные игры? Буду признателен за любой совет :)
5 сообщений пропущено. Для просмотра нажмите «Ответ».
No. 26041  
>>26040
Когда в последний раз смотрел там было много второго.
No. 26061  
Самые интересные варианты: Ren'Py и Unity.

Первый элементарен и максимально прост в освоении, но, поскольку написан на "варп-скорость" языке, то конечный продукт имеет проблемы с быстродействием, особенно на не самых мощных машинах. Имеет неприятные ограничения (с которыми ты не столкнёшься, если будет делать обычную новеллу без мини-игр, например). Кроме того, порт игры на мобильные, опять же, благодаря родительскому языку, пускай и имеет место быть, но является источником боли в пятой точке.

Второй же осваивается сложнее, дольше, но более вариативен, конечный продукт получится более оптимизированным, порт на мобильные/нинтендо заставляет запариться, но получается более качественным. Да и С# приятнее язык, имхо.

Под Unity есть ассет Fungus, что упрощает создание новеллы в разы. Но всегда лучше сделать что-то свое и чисто под себя, не так ли?
No. 26062  
>>26061

>Нинтендо
Это я вброс сделал, никогда таким не занимался и не интересовался даже. Знаю только, что возможность есть такая, но о процессе и связанных проблемах ничего не ведаю.
No. 26084  
>>26061
Каво там оптимизирован? Unity по сравнению с рин паем?
No. 26140  
Почему все так стремятся создавать игры? Мне кажется, что системное программирование должно быть намного интереснее, т.к. это всякие хакерские штучки, но тут проблема только в том, что требуется большое количество глубоких знаний из разных областей компьютерных наук. Либо я сам себя загоняю, отчего забросил. Но формошлёпание и программирование мышкой меня как-то не привлекает.

Если же брать во внимание какие игры меня интересуют, то тут для создания самолётика нужно тоже знать кучу всего, причём без высшего технического образования не обойтись, — та же работа РПО должна представлять собой симуляцию течения масла + симуляцию работы лопастей винта, а иначе она не будет приближённой к реальности. Собственно, поэтому полноценная реализация вертолётов и винтовых самолётов есть только в одной игре DCS, т.к. там очень хитрый матан (и это же единственный авиасим, где есть износ покрышек как в автосимуляторах, если я не ошибаюсь) Но у меня не такой мощный комп, чтобы играть в этом, а также модули в нём дороговаты + простенького джойстика будет недостаточно, отчего попробовать такое элитарное увлечение можно будет лишь тогда, когда найду оплачиваемую работу, а сейчас остаётся лишь смотреть как летают на "Ютубе", да довольствоваться примитивными в 2022 году "старичком" и FS 2004.

>>26033
> Renpy
Зачем нужен Ren'Py, если можно объектов на форму нашлёпать?
No. 26142  
>>26032
Игры - это всё меньше и меньше про разработку. Особенно визуальные новеллы. Тут нужно быть художником, сценаристом, ну и техническим художником (technical artist). А программирование тут дело десятое или двадцатое. При наличии скиллов в 3д дизайне/графике, готовых ассетов, арта, проггера можно найти, чтобы он по косому диздоку всё это слепил вместе. Лепить наверное лучше в ютини, потому что современно, потому что громадное комьюнити, потому что огромный инструментарий, убирающий необходимость кодить каждую второстепенную вещь.
No. 26143  
>>26142
Программирование мышкой, короче.
1383852009227.png - (34.62KB, 355×585)
15850
No. 15850       [Ответ] [Первые 100 сообщений] [Последние 50 сообщений]
Данная нить сделана по согласованию с администрацией Ычана.

У администрации Ычана появилось желание добавить некоторые функции в стандартный пользовательский интерфейс, что требует доработки местного JS. Поскольку специалистов в этой сфере на примете нет, было решено обратиться к сообществу.
Какие функции нужны:
  • Скрытие тредов. Видимо, с использованием localstorage. Учитывайте возможность развернуть тред обратно.
  • Разворот картинки на странице по нажатию на уменьшенную копию. Большие картинки должны разворачиваться не в натуральную величину, а с учётом ширины и высоты окна. По повторному нажатию сворачиваться обратно. Учитывайте, что иногда вместо уменьшенной копии бывает заглушка спойлера, а в огороженном разделе /gf/ есть флэшь-файлы, которые этак разворачивать смысла нет.
Желательно, чтобы скрипты были достаточно легковесны, чтобы помещаться в wakaba.js. Минимальными должны быть и предлагаемые правки вёрстки самих страниц (радикально никто ничего перепиливать не будет).
Предпочтительная лицензия скриптов — общественное достояние (public domain), как у самой «Вакабы».

Пока всё. Администрация не рассматривает идеи подключения куклоскриптов или чего-то подобного тяжеловесного целиком, так как стремится сохранить минимализм интерфейса сайта. Также пока не рассматриваются предложения по неким другим функциям.
461 сообщений и 135 изображений пропущено. Для просмотра нажмите «Ответ».
No. 25694  
Репозиторий вроде все еще жив
https://github.com/WagonOfDoubt/iichan-extensions
И в контрибуторах есть Мицгол, который еще с нами, так что шансы на починку есть.
No. 25705  
>>25694

Эппловскихъ устройств не имѣю, ѿлаживать негдѣ.
No. 25706  
>>25693
Учитывая обстоятельства >>25705 получается, надо создавать issue на гитхабе, чтобы хоть как-то обратить на проблему внимание.
No. 25770  
Кстати, ни у кого не осталось кода для поддержки ЎэбП, который когда-то постили в /d/? Или какой-нибудь новый кот для этого.
No. 25771  
screenshot.webp - (50.65KB, 929×547)
25771
>>25770

http://ii.yakuji.moe/d/res/250303.html#251062
No. 26119  
quote1.webp - (744.43KB, 2459×8483)
26119
Упомянутая в сообщении >>20993 проблема https://trac.ffmpeg.org/ticket/7613 исправлена разработчиками FFmpeg, и предположительный срок её исправления оказался даже больше того, насчёт которого я мрачно подозревал в сообщении >>21078: не только до середины 2021 года, но даже и до февраля 2022 года поневоле пришлось дожидаться.

Дополнительные подробности я изложил в сообщениях https://t.me/ReadMithgol/476 и https://t.me/ReadMithgol/478 в Телеграме, растровые копии которых я прилагаю и тут, но только по одной (а не то итог склеивания их по вертикали, весьма вѣроятно, натолкнулся бы на препятствие >>/d/2649 при малѣйшей попытке помѣстить его на 410чан).
No. 26120  
quote2.webp - (760.39KB, 2458×8743)
26120
Второе приложение к сообщению >>26119.
movie_002.mp4 - (1.15MB, 1068×726)
25313
No. 25313       [Ответ]
Я все же создам новый тред, да простит меня джаббер тред внизу каталога.

Решил вкатиться в юнити. Читаю их туториалы, пока в восторге от доступности и простоты материала (по сравнению с тем, что было раньше)

Буду тут писать отчеты.

Пара ссылок:
Сайт: https://unity.com
Обучение: https://learn.unity.com
Есть тг канал: @unity3d_ru
6 сообщений и 6 изображений пропущено. Для просмотра нажмите «Ответ».
No. 25389  
movie_004.mp4 - (4.27MB, 1280×720)
25389
UI оставил двоякое впечатление, с одной стороны все просто. С другой стороны, чтобы его сделать невырвиглазным, нужно постараться.
No. 25401  
Узнал сейчас про object pooling. Если один и тот же объект планируется создавать и удалять много раз, то гораздо оптимальнее будет инстанциировать лист этих объектов и сделать каждый из них неактивным. Далее, в момент когда объект необходим в сцене, из пула берется один из его инстансов и делается активным. При этом могут меняться некоторые из его параметров (например позиция).

Ну и соответственно, если активный объект больше не нужен, но не удаляется, а делается неактивным. Пул всегда возвращает один из неактивных объектов, то есть не используемых в данный момент.

В итоге получается, что мы имеем в памяти постоянное количество объектов (равный размеру пула), а не постоянно создаем и удаляем бесконечное количество объектов по мере работы сцены.
No. 25412  
Unity вкатывается в настоящую мультипоточность и асинхронность. В то время как в мире микросервисов это давно стандарт, в таких больших проектах похоже не так все просто.

До сих пор в стейбл версии используется старый подход, при котором главный цикл обновления сцены однопоточен. Сейчас (точнее еще в 2018) нашли способ это сделать многопоточным со скедулингом по разным ядрам. Правда это до сих пор в превью, хотя и выглядит вполне надежно и многообещающее.

Основная фишка тут в том, что подобный подход требует изменений в структурах пользовательского кода и объектов. Для этого были придуманы конверторы, и это вылилось в отдельную версию редактора. Пользователь работает с игровыми объектами и их компонентами, как и раньше. А дальше они сами конвертируются в “новые” сущности и компоненты (Entity Component System) для работы с ними в коде.

Ну и в коде, в связи с этим, уже нет работы с игровыми объектами в их обычном понимании, а с компонентами напрямую, которые в свою очередь уже содержат какие-то данные (например позиция, скорость). Отсюда этот подход получил название Data-Oriented Technology Stack. Классы теперь наследуются не от MonoBehaviour, а от JobComponentSystem.

https://unity.com/dots
Ну и разумеется, все это стало гораздо производительнее, и стало возможным делать сложные сцены, работающие даже на мобилках https://www.youtube.com/watch?v=KgcU2HBOXAw
No. 25423  
Погуглил больше про ECS.

Концепция сама существует давно и не является изобретением Unity, но уже DOTS - их термин. Она сама по себе не про производительность, а про подход к описанию игрового мира и взаимодействий в нем.

В ECS игровые объекты не наследуют кучу всего и не создаются со статичной кучей параметров и компонентов, существующих вплоть о момента удаления объекта. В ECS игровые объекты - просто entities, некие изначально пустые "сущности", играющие роль уникальных идентификаторов.

Параметры игровых объектов (например, здоровье, скорость, "прыгучесть", etc) являются самостоятельными компонентами (components), не привязанными ни к какому объекту статично. Они могут назначаться каким-либо entities, если им необходимо данное поведение/характеристика. Причем эта привязка или отвязка происходят в рантайме, что позволяет делать классные вещи в виде изменения казалось бы статичных характеристик игрового мира в уже работающих клиентах.

Системы (systems) содержат уже логику, обрабатывающую данные из компонентов. Можно думать о них, как о контроллерах. Важно то, что системы не завязаны на конкретных компонентах и entities. По крайней мере в юнити, как я понял, системы могу выбирать entities на основе привязанных к ним компонентов (entity query) и тем самым всегда работают с группой entities. Поэтому в коде много foreach :)

В этой концепции Entities, Components и Systems - вещи изначально существующие обособленно друг от друга, и им нужны отдельные средства коммуникации. И тут уже все зависит от конкретной имплементации.
No. 25450  
movie_005.mp4 - (436.97KB, 854×480)
25450
Разобрался со сценами и переходами между ними. Сцена - это некая уникальная инстанция мира. В зависимости от сложности игры может быть отдельным уровнем, может быть целым открытым миром. Или это может быть просто menu screen.

Все игровые объекты создаются внутри сцены и при переходе между сценами удаляются. Однако есть различные методики для персиста данных между сценами. Самый простой способ - это использование синглтона, который один раз создается при инициализации и помечается, как неудаляемый.

Персист данных между сессиями (между разными запусками игры) сложнее. Причем не потому, что надо писать в файл или работать с другими внешними сущностями. А потому что надо постоянно думать, могут ли внутренние структуры быть сериализированы. В шарпе не все так однозначно. Обычный array, например, может быть сериализирован в json, List уже нет. Хотя BinaryFormatter с ним справляется без проблем.
No. 25670  
бамп

Стив, как дела, продвигается ли изучение?
No. 26109  
maxresdefault.jpg - (88.78KB, 1280×720)
26109
>>25670
Забил на какое-то время. Переезды, смена работы и всё такое
Ещё как закончил курс junior programmer, у меня случился overwhelm от осознания уровня необходимых скиллов (которые нужно качать и качать 100500 лет как в олдскулл ммо), что демотивировало продолжать процесс.

Недавно появилось желание раздропнуть. Начал новый курс Creative core. Посматриваю на применения Юнити в не-игровых индустриях, изучаю какие есть наработки в AR, webrtc, нативная интеграция в мобилках и всё такое.
No. 9999       [Ответ] [Первые 100 сообщений] [Последние 50 сообщений]
http://sourceforge.net/projects/rr-rr/
Предыдущий тред: >>4274
144 сообщений и 76 изображений пропущено. Для просмотра нажмите «Ответ».
No. 25030  
10 лет прошло с начала разработки. Технологии рендера изменились до неузнаваемости. Уже делают рилтайм рейтрейсинг с постобработкой нейроночками, и все это с аппаратной поддержкой.
...
А ты копаешь ассемблерный код сравнения чисел.
No. 25117  
>>25030
Я конечно понимаю, что бесконечное копание ассемблерного кода это самоцель проекта, но почему бы по-быстрому не набросать то же самое на юнити. Мне кажется концепт сам по себе вполне играбелен, и достоин того, чтобы принять более-менее оконченный вид.
No. 25121  
>>24739
Я удалил старые билды, а из исходников скомпилировать нельзя (на самом деле можно, но, пожалуйста, просто не пытайся). Всё будет, главное сейчас сидеть тихо и не бухтеть.

>>25117
Я не буквально «бесконечно копаюсь в ассемблерном коде» (хотя и занимаюсь чем-то близким по осмысленности), я и ассемблер-то почти не знаю. Просто написал под впечатлением, что вот, смотрите, интринсики завезли. BTW:
>>25030
>10 лет прошло ... Технологии рендера изменились до неузнаваемости.
Всё ясно, автору 10 лет.
Да нет, почти всё придумано в прошлом веке. ЭВМ Наири-3 поддерживала разделение времени и эмуляцию других ЭВМ. Рейтрейсинг и нейросети использовали ещё раньше.

>занимаюсь чем-то близким по осмысленности
Например, я буквально пару дней назад догадался сделать хранение базиса касательного пространства в вершине не обычными 2 векторами (нормаль + касательная, 3-й восстанавливается в шейдере через их cross), а кватернионом, т. к. этот базис, в предположении, что не может быть разортонормализован или отражён, представляет собой поворот некоторого исходного базиса — скажем, X = (1, 0, 0), Y = (0, 1, 0), Z = (0, 0, 1).

Ну, это старая идея и я давно читал про неё, но мне не хватало точности при хранении кватерниона как непосредственных X, Y, Z в 10-10-10 битах с восстановлением в шейдере W через √(1−x²−y²−z²), а хранить с лучшей точностью смысла нет (не будет выигрыша относительно 2 векторов). Теперь же я прочитал про идею (вот здесь в конце: https://archive.org/stream/GDC2015McAuley/GDC2015-McAuley_djvu.txt) отбрасывать не W, а максимальный по модулю компонент, и в 2-битовом W сохранить индекс отброшенного компонента. То есть кватернион (X, Y, Z, W) пакуется в один из вариантов:
(Y, Z,&
Сообщение слишком длинное. Полный текст.
No. 26014  
Тред умер?
No. 26015  
>>26014
А ты думал, аффтору потребовалось если ответить 4 месяца на вопрос о пропаже билдов, и так их и не залить.
Но вроде что-то пилит.
No. 26016  
>>26014 >>26015
Сказал же буквально на днях, всё будет, хорош шуметь.
>Третий тролль сказал: «Прощайте! Ненавижу болтунов».

За прошлый год я, хотя ничего не делал, стал парадоксальным образом в промышленных масштабах натыкаться на баги Free Pascal, отчего потерял терпение и повадился громко плакать о них на багтрекере в противоположность тому, как ранее натыкался на них раз в год и обходил переформулированием кода. Последние две недели плотно занимался https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/179, а вообще из всего, в чём засветился, мне больше всего нравится https://gitlab.com/freepascal.org/fpc/source/-/issues/39360 («копание в ассемблерном коде», да). Не подумайте, мне были жесть как нужны, соответственно, карманная база Юникода и ускорение генерации шума Перлина до уровня, когда текстуру с ним можно генерировать на месте, а не таскать с собой, здесь нет никаких проблем с приоритетами. Ну или, может, и есть самая малость, но кто сказал, что я прямо сейчас не возьму и не пойду дорисовывать Сырну?!
No. 26018  
>>26016
>Сказал же буквально на днях
Где??
Но вообще, контрибы в язык - это ты малаца, завидно даже.
No. 25954       [Ответ]
Делаю свою буру и не понимаю, как сделать теги. Хочу за O(1) отвечать на вопрос вида "какие ID у картинок с тегами t1,...,tn, но без тегов e1,...,en, на странице с оффсетом 12000?" Ну или формально доказать, что я обнаглел и это невозможно. Как вы это делаете?
No. 25955  
> какие ID у картинок с тегами t1,...,tn, но без тегов e1,...,en
Создаешь инвертированный индекс, где к каждому тегу привязана кишка с айдишниками соответствующих документов. Итерируешься по одной из кишок (ты можешь выбрать самую короткую), получаешь сложность O(длина кишки). Так делается в больших нагруженных поисковых системах.
> на странице с оффсетом 12000
Добавляешь еще один тег (поисковый литерал), означающий номер страницы.

Возможно, на маленькой буре можно сделать что-то более быстрое по времени, но за счет большего потребления памяти. Я не уверен, что это на самом деле нужно.
No. 25957  
О, а мысль протегировать страницы мне не приходила в голову.
No. 25958  
>>25954
Разве такое не должно быть уже решено в СУБД?
Но гляньте https://roaringbitmap.org/
Если в кратце, для каждого тэга храним сжатый битовый массив, для выполнения запроса and-аем чанки этих массивов между собой, делая popcnt по результату, пока не достигнем нужный offset.
No. 26010  
1418651108864.png - (28.27KB, 225×239)
26010
Моя бура состоит из двух TSV текстовых файлов вида тэг|хэш и хэш|путь-к-файлу, которые я грепаю скритом.

What is O(1), is it tasty
Medieval-CUE-Splitter-icon.png - (71.68KB, 256×256)
25890
No. 25890       [Ответ]
Дано: рип виниловой пластинки в двух .flac файлах (side A и side B соответственно), .cue(1шт.), .m3u(1шт.)
Указанная программа при попытке порезать два файла на треки создаёт .flac файл с названием первого трека первого файла(side A)размером 33КБ + .cue и . m3u к нему.
Видел в сети ещё одного бедолагу с такой же проблемой, ему советовали ставить какие-то кодеки и вообще воспользоваться другой программой.
Решения проблемы не нашёл, а потому прошу помощи у вас.

Исходный аудиофайл: https://rutracker.org/forum/viewtopic.php?t=5768831
No. 25891  
cuesp.png - (56.61KB, 648×534)
25891
Странную продолжительность имеют пятый и десятый трек(пикрил).
No. 25893  
REM GENRE New Wave, Post-Punk
REM DATE 2019 (1979)
REM COUNTRY EU
REM LABEL Factory
REM CATALOG FACT 10 40
REM ASDFVL_VinylRip
PERFORMER "Joy Division"
TITLE "Unknown Pleasures"
FILE "Joy Division - Unknown Pleasures - Side A.flac" WAVE
TRACK 01 AUDIO
TITLE "Disorder"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Day Of The Lords"
INDEX 01 03:31:35
TRACK 03 AUDIO
TITLE "Candidate"
INDEX 01 08:20:00
TRACK 04 AUDIO
TITLE "Insight"
INDEX 01 11:27:00
TRACK 05 AUDIO
TITLE "New Dawn Fades"
INDEX 01 15:52:00
FILE "Joy Division - Unknown Pleasures - Side B.flac" WAVE
TRACK 06 AUDIO
TITLE "She's Lost Control"
INDEX 01 00:00:00
TRACK 07 AUDIO
TITLE "Shadowplay"
INDEX 01 03:56:00
TRACK 08 AUDIO
TITLE "Wilderness"
INDEX 01 07:51:00
TRACK 09 AUDIO
TITLE "Interzone"
INDEX 01 10:32:00
TRACK 10 AUDIO
TITLE "I Remember Nothing"
INDEX 01 12:48:00
No. 25895  
Воспользовался программой XRECODE 3, вес треков на выходе составил ~2.8Гб против ~1.5Гб исходных.
Предстоит разобраться...
No. 25896  
Потыкал галочки. Получил файлы весом в 6.88Гб.
No. 25945  
Вообще используют shnsplit/cuetools в зависимости от системы. А что касается cue, то этот вообще можно разбить на два файла и получить типичное один flac - один cue, это просто текстовый файл бля, кури мануалы:
https://wiki.hydrogenaudio.org/index.php?title=Cue_sheet
https://en.wikipedia.org/wiki/Cue_sheet_(computing)
https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Frames_and_timecode_frames

И не знаю чего ты тут пишешь, я тут особенной активности не замечал. Если знаешь буржуйский, я бы порекомендовал зарегатся на OPS.
https://interview.orpheus.network

>>25893
если у файлов продолжительность действительно ~20 минут, то вина наверняка в тупой программе
No. 25946  
x2.png - (39.00KB, 573×620)
25946
>>25895
Воспользовался программой XRECODE2, всё получилось.
Могу предположить что виной огромного веса треков была это галочка.
410.png - (34.48KB, 500×500)
20450
No. 20450       [Ответ] [Первые 100 сообщений] [Последние 50 сообщений]
После публикации исходников мы можем обсуждать доработку не только ранее общедоступных частей интерфейса, но и движка в целом.

Репозиторий: https://bitbucket.org/Therapont/fbe-410
1. Для ваших предложений предназначена ветка public.
2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория).
3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным.
4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует.

Предыдущая нить: >>17371
494 сообщений и 220 изображений пропущено. Для просмотра нажмите «Ответ».
No. 25926  
Я смотрю, исправление ссылок при объединении нитей сломалось.
Автор ещё тут хоть?
No. 25927  
>>25926
При объединении, или при переносе?
No. 25928  
>>25927
Объединении. Причём раньше работало.
Пример: >>/b/157239, начиная с >>/b/173234
No. 25929  
>>25928
Ага, вижу, превью работает корректно, а сама ссылка при этом неправильная, со старой нитью.
No. 25930  
>>25926
>>25929
Починил и создал пулреквест.
Оказалось настолько тривиально, что даже стыдно за такое.
No. 25935  
В пулл-реквесте с предупреждениями автор добавил экранирование ХТМЛ для модлога, но не учёл, что таким образом ломаются ссылки для просмотра удалённых сообщений. Мы пока вернули эту строку, дабы ссылки работали, но настоятельно рекомендуем найти способ починки этой лабуды, ибо оно не позволяет использовать ХТМЛ в предупреждениях.
No. 26068  
>>26066
Удалить сообщение []
Пароль  
[Mod]
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]