[+] [2560] Продолжительность песен округляется к большему значению (2)

[ntai]

(название отсюда: https://www.aimp.ru/forum/index.php?topic=70772)

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

[Artem]

Трек не должен играть больше, чем отображается.

[«G-Li†ch»]

Ну, фактически, при настройках по умолчанию AIMP и так их играет короче чем у "округленных в меньшую сторону", т.к. по умолчанию включено сведение. А если ещё и удаление тишины в начале/конце, ооой… В общем, абсурд.

[Artem]

Ну, фактически, при настройках по умолчанию AIMP и так их играет короче чем у "округленных в меньшую сторону", т.к. по умолчанию включено сведение. А если ещё и удаление тишины в начале/конце, ооой… В общем, абсурд.

Опять начинается передергивание... 

[ntai]

Трек не должен играть больше, чем отображается.

не совсем понимаю, почему, честно говоря. я на всякий случай пооткрывал тот же файл во всех возможных программах, и все они показывают значение, округлённое в меньшую сторону.

я к чему: это не просто эстетический вопрос. при экспорте плейлиста приходится поправлять длительности.

[Artem]

Вообще говоря, вы не совсем правы:
1) Часть программ просто отсекает миллисекунды
2) Часть программ округляет математически
3) Часть программ показывает миллисекунды

У меня миллисекунды округляются всегда в большую сторону, показывая, что файл играет не больше, чем указано.

Если в плейлисте написано 0:01, это может быть и 0.6, и 1.4 - совсем разные величины, не так ли?
Когда подбираешь музыку или сэмплы - это весьма критично.

Я сделал такое поведение ровно потому, что существующие варианты меня как пользователя не устраивали.
P.S. Весь AIMP так изначально и зародился =)

[ntai]

да, спасибо за ответ. теперь понимаю. хорошо было бы, конечно, иметь опции на каждый чих...

[Artem]

да, спасибо за ответ. теперь понимаю. хорошо было бы, конечно, иметь опции на каждый чих...

Полагаю, что исключительно для миллисекунд? Просто сейчас алгоритм один для всех единиц времени.

[ntai]

Полагаю, что исключительно для миллисекунд? Просто сейчас алгоритм один для всех единиц времени.

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

меня просто в своё время действительно удивило, что аимп так непривычно эти длительности считает. хотя здесь важно, волнует ли это ещё кого-нибудь, кроме меня.

upd. при том, что округление в меньшую сторону, а, вернее, представление целого числа без миллисекунд — стандарт.

[ss.pl]

миллисекунды тоже были бы полезны, да

убраны по просьбам трудящихся

[ntai]

убраны по просьбам трудящихся

так я помню, да. поэтому и говорю: через опцию. интересная же фича

[«G-Li†ch»]

В случае с WAV PCM, лучше обращать внимание не на длительность "в секундах", а на размер файла + частоту дискретизации (ну и моно/стерео)… А там приблизительно можно и до пары тысяч отсчётов подсчитать
Хотя, частенько замечаются 24-разрядные семплы… вот тут уже становится сложнее…
А в редакторах-то да, частенько использую привязку к сетке в 1 sample (соответственно, по временной линейке трудно узнать сколько минут:секунд.мсек)…

[Artem]

В случае с WAV PCM, лучше обращать внимание не на длительность "в секундах", а на размер файла + частоту дискретизации (ну и моно/стерео)

Не смешно