AIMP Forum
AIMP for PC => Ошибки и замечания / Bugs => Обработано / Processed => Topic started by: ntai on August 01, 2024, 18:47:07
-
(название отсюда: https://www.aimp.ru/forum/index.php?topic=70772 (https://www.aimp.ru/forum/index.php?topic=70772))
само по себе это не страшно, но я заметил, что все основные стриминговые сервисы, магазины и музыкальные базы данных округляют длительность треков к меньшему значению — отсюда постоянная разница в секунду (см. вложение). поэтому хотел спросить: не было бы более логичным использовать такое же округление, как и везде? или, например, добавить возможность выбирать в настройках через галочку.
-
Трек не должен играть больше, чем отображается.
-
Ну, фактически, при настройках по умолчанию AIMP и так их играет короче чем у "округленных в меньшую сторону", т.к. по умолчанию включено сведение. А если ещё и удаление тишины в начале/конце, ооой… В общем, абсурд.
-
Ну, фактически, при настройках по умолчанию AIMP и так их играет короче чем у "округленных в меньшую сторону", т.к. по умолчанию включено сведение. А если ещё и удаление тишины в начале/конце, ооой… В общем, абсурд.
Опять начинается передергивание...
-
Трек не должен играть больше, чем отображается.
не совсем понимаю, почему, честно говоря. я на всякий случай пооткрывал тот же файл во всех возможных программах, и все они показывают значение, округлённое в меньшую сторону.
я к чему: это не просто эстетический вопрос. при экспорте плейлиста приходится поправлять длительности.
-
Вообще говоря, вы не совсем правы:
1) Часть программ просто отсекает миллисекунды
2) Часть программ округляет математически
3) Часть программ показывает миллисекунды
У меня миллисекунды округляются всегда в большую сторону, показывая, что файл играет не больше, чем указано.
Если в плейлисте написано 0:01, это может быть и 0.6, и 1.4 - совсем разные величины, не так ли?
Когда подбираешь музыку или сэмплы - это весьма критично.
Я сделал такое поведение ровно потому, что существующие варианты меня как пользователя не устраивали.
P.S. Весь AIMP так изначально и зародился =)
-
да, спасибо за ответ. теперь понимаю. хорошо было бы, конечно, иметь опции на каждый чих...
-
да, спасибо за ответ. теперь понимаю. хорошо было бы, конечно, иметь опции на каждый чих...
Полагаю, что исключительно для миллисекунд? Просто сейчас алгоритм один для всех единиц времени.
-
Полагаю, что исключительно для миллисекунд? Просто сейчас алгоритм один для всех единиц времени.
миллисекунды тоже были бы полезны, да. не всегда хочется открывать рипер (или любой другой редактор), чтобы измерить и сравнить. но я в первую об округлении, всё-таки. здесь бы просто пришлось в алгоритме дополнительно отнять единицу. и это, опять же, больше для музыки, когда первый вариант скорее для файлов разного происхождения.
меня просто в своё время действительно удивило, что аимп так непривычно эти длительности считает. хотя здесь важно, волнует ли это ещё кого-нибудь, кроме меня.
upd. при том, что округление в меньшую сторону, а, вернее, представление целого числа без миллисекунд — стандарт.
-
миллисекунды тоже были бы полезны, да
убраны по просьбам трудящихся (https://www.aimp.ru/forum/index.php?topic=67881.0)
-
убраны по просьбам трудящихся (https://www.aimp.ru/forum/index.php?topic=67881.0)
так я помню, да. поэтому и говорю: через опцию. интересная же фича
-
В случае с WAV PCM, лучше обращать внимание не на длительность "в секундах", а на размер файла + частоту дискретизации (ну и моно/стерео)… А там приблизительно можно и до пары тысяч отсчётов подсчитать :)
Хотя, частенько замечаются 24-разрядные семплы… вот тут уже становится сложнее…
А в редакторах-то да, частенько использую привязку к сетке в 1 sample (соответственно, по временной линейке трудно узнать сколько минут:секунд.мсек)…
-
В случае с WAV PCM, лучше обращать внимание не на длительность "в секундах", а на размер файла + частоту дискретизации (ну и моно/стерео)
Не смешно