Total Commander

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

Код: Выделить всё

		<!-- General -->
		<column name="Duration">
			<unit name="hh:mm:ss" type="script">Output:=TimingFormat('%hh:%mm:%ss', Duration);</unit>
			<unit name="hh:mm:ss.fff" type="script">Output:=TimingFormat('%hh:%mm:%ss.%fff', Duration);</unit>
			// FIXES: Show Duration in second
			<unit name="sec" type="script">Output:=Round(Number(Duration)/1000);</unit>
			// FIXES: Show Duration in millisecond
			<unit name="msec">Duration</unit>
			// FIXES: Show Duration Custom
			<unit name="Custom" type="script">
			<![CDATA[
				Output:='';
				if (Duration <= 0) then Exit;
				if Not StrIsNumber(Duration) then Exit;
				Secs := Integer(Duration / 1000); //convert miliseconds to seconds
				Hours := Integer(Secs / 3600); //3600 seconds in an hour
				Mins := Integer((Secs - (Hours * 3600)) / 60); //60 secs per min
				Secs := Secs - ((Hours * 3600) + (Mins * 60)); //leftovers
				If (Hours < 10) then Hours := '0' + String(Hours);
				If (Mins < 10) then Mins := '0' + String(Mins);
				If (Secs < 10) then Secs := '0' + String(Secs);
				Output := StrFormat('%s:%s:%s', Hours, Mins, Secs))
			]]>
			</unit>
		</column>

Этот вариант полностью соответствует отображению MediaInfo, что подтверждаю скрином. Дело в том, что многие при подсчете продолжительности расчет ведут от округленных секунд, что конечно неправильно. Даже K-Lite Codeck Pack считает неправильно. Что видно на скрине. Хотелось-бы увидеть эти изменения в плагине, для стандартных форматов продолжительности. Чтобы у всех были одинаковые данные. Еще нашел косячки в последнем TCMediaInfo.xml. Из-за чего не отображались год, наличие обложки и комменты аудио-файлов. Еще там кое-какие обновления. Опять-же, если сочтете нужным, включите эти изменения в новую версию плагина. https://www.dropbox.com/scl/fi/g17ie6ra ... dqx6l&dl=1
Я конечно и сам сейчас выложу на ру.борде эту информацию. Но очень-бы хотелось, чтобы это было единоообразно для всех.

На скрине первая колонка продолжительности мой кастом, вторая - ваша стандартная.

AkulaBig
А в чем весь сыр-бор-то? Что последняя секунда не так округляется? Да и фиг с ней

Ну а если серьёзно, там же есть фреймы для уточнения, т.е. например Duration, hh:mm:ss.fff = 00:08:16.526

Или я что-то не понимаю?

[cut]
Кстати, спасибо за сборку! Единственная сборка где я нашел полноценный набор архиваторов. Вы спросите зачем оно мне? Для порядку! Мало ли, вдруг понадобится в ARJ или ACE упаковать что-нибудь

[/cut]

Orion9 писал(а):AkulaBig
А в чем весь сыр-бор-то? Что последняя секунда не так округляется? Да и фиг с ней

Не порядок, когда есть разночтение с MediaInfo, раз плагин ей пользуется.

Orion9 писал(а):AkulaBig
[cut]
Кстати, спасибо за сборку! Единственная сборка где я нашел полноценный набор архиваторов. Вы спросите зачем оно мне? Для порядку! Мало ли, вдруг понадобится в ARJ или ACE упаковать что-нибудь
В последней сборке я наконец-то выкинул весь этот варез. Работает только распаковка этих форматов.
[/cut]

AkulaBig писал(а):Дело в том, что многие при подсчете продолжительности расчет ведут от округленных секунд, что конечно неправильно.

Если вести не от округлённых, то получается, что в расчете тайминга мы просто отбрасываем миллисекунды. Что, собственно, и делалось в TimingFormat до всех сентябрьских модификаций (да, там все равно был косячок в округлении до десятых/сотых при наличии спецификаторов %f, но он не связан с округлением до целых секунд, в этом случае миллисекунды отбрасывались).

В вашем Custom эта строка просто обрезает полученное дробное число секунд до меньшего целого, никакого округления не производится:

Код: Выделить всё

Secs := Integer(Duration / 1000); //convert miliseconds to seconds

Что приводит вывод к старому варианту

AkulaBig писал(а):Этот вариант полностью соответствует отображению MediaInfo, что подтверждаю скрином.

Разумеется, потому что MediaInfo при форматировании не округляет, а отбрасывает миллисекунды.

AkulaBig писал(а):Опять-же, если сочтете нужным, включите эти изменения в новую версию плагина.

Посмотрю, но не очень скоро, вижу там много чего.

AkulaBig писал(а):Не порядок, когда есть разночтение с MediaInfo, раз плагин ей пользуется.

А вот это как раз ни к чему не обязывает, поскольку MediaInfo используется только как источник сырых данных. То, что выводит GUI-версия - это уже отформатированные данные. Единственные данные, которые обязаны быть одинаковы - это полный тайминг вида 00:08:16.526, всё остальное зависит от метода расчета и предпочтений пользователя.

Loopback писал(а):
AkulaBig писал(а):Дело в том, что многие при подсчете продолжительности расчет ведут от округленных секунд, что конечно неправильно.
Код: Выделить всё
Secs := Integer(Duration / 1000); //convert miliseconds to seconds
Что приводит вывод к старому варианту

Эта строка как раз у меня вопросов не вызывает. Понятно, что она является округлением до секунд по правилам математики. А вот при преобразовании в часы, минуты, секунды не надо округлять секунды, а потом от этого округления высчитывать продолжительность. То-есть обсуждать стоит только блок Custom.

Loopback писал(а): В вашем Custom эта строка просто обрезает полученное дробное число секунд до меньшего целого, никакого округления не производится:
Код: Выделить всё
Secs := Integer(Duration / 1000); //convert miliseconds to seconds

Это очень тонкий момент. К сожалению под рукой нет учителя математики, чтобы подтвердить правоту этого выражения. Похоже это соответствует правилам именно при преобразовании в часы, минуты, секунды. В любом случае MI работает именно по подобному алгоритму.

Loopback писал(а):Разумеется, потому что MediaInfo при форматировании не округляет, а отбрасывает миллисекунды.

Как я писал выше, видимо именно так должно происходить преобразование. Может у вас есть толковое словесное описание, как должно происходить преобразование? Я такого в инете не нашел. Я думаю тут причина в том, что есть разница между округлением и преобразованием. Ведь это не округление.

Loopback писал(а): Посмотрю, но не очень скоро, вижу там много чего.

Конечно оставьте это до появления свободного времени. Лично меня кастомное поле вполне устраивает. И вам я написал только для того, чтобы сделать отображение одинаковым для всех. А остальные изменения да, тоже хотелось-бы учесть. Я совершенно случайно заметил, что некоторые поля не отображаются. Посмотрел, у вас оказывается в последних версиях плагина очень изменился алгоритм xml, поэтому и вылез косяк. Я просто эти строки из старого xml взял. Кстати, остальные поля я не проверял. Только те, что заметил.

Loopback писал(а): То, что выводит GUI-версия - это уже отформатированные данные.

Дак в этом и дело, что мы не можем отследить алгоритм преобразования. В CLI показывает часы, минуты, секунды. Но конечно это уже форматированный вывод. Скажем так, мой вывод совпадает с выводом MediaInfo и я считаю его правильным.

Не порядок, когда есть разночтение с MediaInfo, раз плагин ей пользуется.

Понятно. Как говорилось в одном фильме: "Упорядочивание хаоса - очень прибыльное дело"

Но если вопрос только в округлении последней секунды, не кажется ли вам, что это больше смахивает на дилемму о наполовину полном и наполовину пустом стакане? )

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

AkulaBig писал(а):А вот при преобразовании в часы, минуты, секунды не надо округлять секунды, а потом от этого округления высчитывать продолжительность.

Так в том-то и дело, что сейчас именно так работает TimingFormat. После внесенных в сентябре изменений. И тогда такой вариант был сочтен правильным. И если сейчас

Хотелось-бы увидеть эти изменения в плагине, для стандартных форматов продолжительности.

их приводить к одному варианту, то к какому? Потому что сейчас ваш Custom - миллисекунды обрезает, а стандартный TimingFormat - миллисекунды округляет.

AkulaBig писал(а):Это очень тонкий момент. К сожалению под рукой нет учителя математики, чтобы подтвердить правоту этого выражения. Похоже это соответствует правилам именно при преобразовании в часы, минуты, секунды. В любом случае MI работает именно по подобному алгоритму.

Внутренне функция Integer - это дельфийская функция Trunc, которая просто отсекает дробную часть.

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

Преобразование так или иначе будет включать в себя избавление от миллисекунд (дробной части). И этот процесс - вопрос реализации. Нет "правильных" и "неправильных", есть просто разные подходы. Если не брать банковскую специфику их три: округление по математическим правилам (Round), до меньшего (Floor) и большего (Ceiling). MediaInfo использует Floor. Плагин тоже использовал его, в сентябре переделали на Round.

AkulaBig писал(а):Дак в этом и дело, что мы не можем отследить алгоритм преобразования.

Исходники MediaInfo открыты...

Ну вот по-видимому оно, в этом файле функция Duration_Duration123. Насколько я могу судить, округления тут не производится.

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

File name : Donna Summer - I Feel Love (Extended Mix).mp3
File size : 18.9 MB (19 865 536 bytes)
-
Duration : 8:16.524 (21 896 687 samples)
Sample rate : 44100 Hz
Channels : 2
Bitrate : 320 kbps
Codec : MP3
Codec profile : MP3 CBR
Encoding : lossy
Tag type : id3v2.4|id3v1

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

Loopback писал(а): Так в том-то и дело, что сейчас именно так работает TimingFormat. После внесенных в сентябре изменений.

В том-то и дело, что работает не так. Я для этого и привел скрин. Не соответствует длительности MediaInfo.

Loopback писал(а): И тогда такой вариант был сочтен правильным.

Мы тогда тестировали файл длительностью 02:36. Он и сейчас показывает правильно.

Loopback писал(а): их приводить к одному варианту, то к какому?

Естественно к варианту, который показывает MediaInfo, иначе я не последний, кто обратит на это внимание. Если-бы MI показывала-бы только миллисекунды, вопросов-бы не было. Но MI показывает продолжительность в разных форматах, в том числе и в ч, м, с. И тут сразу возникает вопрос. А почему у вас длительность не совпадает? Ведь вы используете эту библиотеку.

Loopback писал(а):
AkulaBig писал(а):А вот при преобразовании в Внутренне функция Integer - это дельфийская функция Trunc, которая просто отсекает дробную часть.
Вы меня не поняли. Учитель сказал-бы правильный математический алгоритм. Назначение функций программирования я и сам знаю.
Loopback писал(а): Нет "правильных" и "неправильных", есть просто разные подходы.
Я думаю, что есть один правильный алгоритм. Но это вопрос дискуссионный. Нет смысла его обсуждать. Я могу допустить, что автор MI не прав.
Loopback писал(а): Исходники MediaInfo открыты...
А я не смог ссылку найти. Спасибо.

Добавлено спустя 4 минуты:

Loopback писал(а):Насколько я могу судить, округления тут не производится.
Ну да.
//Seconds
Sec=(int32s)(MS/1000); //s

Добавлено спустя 2 минуты:

Orion9 писал(а):Поэтому самым правильным и точным вариантом, имхо, является отображение времени воспроизведения в полном формате, как, например, это делает foobar2000:
Интересно. Проверю.

AkulaBig писал(а):В том-то и дело, что работает не так. Я для этого и привел скрин. Не соответствует длительности MediaInfo.

Естественно, потому что текущая версия TimingFormat - округляет. Согласно вот этому запросу. Если взять релизную 1.1.0, там будет совпадать с MediaInfo...

AkulaBig писал(а):Мы тогда тестировали файл длительностью 02:36. Он и сейчас показывает правильно.

Вообще-то длительность его была 02:36,499, которая согласно мат. правилам округляется в меньшую сторону до 2:36.

Уверен, что полная длительность всех "расходящихся" значений, выделенных на скрине, имеет 500 или больше миллисекунд.

AkulaBig писал(а):Естественно к варианту, который показывает MediaInfo, иначе я не последний, кто обратит на это внимание

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

Loopback писал(а):Верну исходный вариант с обрезкой по умолчанию

Действительно. Исходный вариант показывает согласно данным MediaInfo. Сейчас еще уточню по foobar2000. Он, как и все остальные плееры показывает с округлением. Но это на линейке. В свойствах вообще продолжительность не показывает.
Я тогда не знал, как MediaInfo пользоваться. Кстати, а вот встроенный плеер Гислера показывает тоже согласно MediaInfo. В этом вроде ничего удивительного нет, учитывая, что у меня настройка использовать внешние кодеки. В которых используется и MediaInfo. Надо скачать LAV-фильтры, удалить кодек-пак и посмотреть, что покажет.

Добавлено спустя 3 минуты:

Orion9 писал(а): foobar2000:

File name : Donna Summer - I Feel Love (Extended Mix).mp3
File size : 18.9 MB (19 865 536 bytes)
-
Duration : 8:16.524 (21 896 687 samples)
Sample rate : 44100 Hz
Channels : 2
Bitrate : 320 kbps
Codec : MP3
Codec profile : MP3 CBR
Encoding : lossy
Tag type : id3v2.4|id3v1

А как можно эти данные посмотреть? Я скачал первую попавшуюся сборку, там в свойствах файла очень скудную инфу показывает.

Добавлено спустя 19 минут:

Попробовал выше приведенный вариант со встроенным плеером Гислера. Учитывая, что MediaInfo вообще удалена и никак не участвует в выдаче информации. Гислер показывает согласно нашим данным.
Пытаюсь понять логику. Для себя так определился. Сначала мы ищем часы, затем минуты, затем секунды. А не сначала секунды. Видимо на этом и основан правильный алгоритм. Просто на форуме утверждали, что автор mp3tag на этом собаку съел и его решение единственно правильное. И большинство плееро-писателей пошли по этому пути.

А как можно эти данные посмотреть? Я скачал первую попавшуюся сборку, там в свойствах файла очень скудную инфу показывает.

Зачем сборку, когда есть чистая версия:
https://www.foobar2000.org/download
При установке можно выбрать Portable. Плюс отдельная куча компонентов расширяющих функционал:
https://www.foobar2000.org/components

Автор, если не ошибаюсь, один из соразработчиков самых первых версий Winamp, т.ч. собаку он съел не меньшую на этом деле, если не бОльшую

Для прослушивания на компе я, конечно, пользуюсь PotPlayer, но foobar2000, имхо, - крутой технический инструмент. В основном, я использую его фичу ReplayGain для нормализации звука MP4 и MKV файлов для медиаплеера, а также пользуюсь его продвинутым конвертером. Но там еще много другого классного функционала и фич, которые, как правило, идут уже в отдельных компонентах.

Сначала мы ищем часы, затем минуты, затем секунды. А не сначала секунды.

Кто-нибудь может на пальцах объяснить, чем этот способ лучше получения секунд с округлением и уже из них получения часов и минут?
Снова про "02:36" не надо, пусть примерами будут, например, "00:01:59.400" и "00:01:59.600", они же 119400 и 119600 мс.

Orion9 писал(а): Зачем сборку, когда есть чистая версия:

Неудачный пример получился. foobar в свойствах показывает только с миллисекундами. Я другого вида отображения и в стандартной версии не нашел. А в линейке показывает округленный до секунда. И вопрос остается.

Добавлено спустя 6 минут:

Skif_off писал(а): Кто-нибудь может на пальцах объяснить, чем этот способ лучше получения секунд с округлением и уже из них получения часов и минут?

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

Total Commander

[wlx/wdx] TCMediaInfo