Потому что этого все равно не хватит чтобы всегда вместить информацию по анаморфу.

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


Самый наиширокий вариант анаморфа (все-все цифры разрешения 4х-значные) в этом найденном мною примере:


Если интервал между полями почти убрать, то всего лишь чуть-чуть придется урезать ширину поля FPS, чтобы влез даже 4х-значный вариант.
Семпл 4-значного примера: http://multi-up.com/557988

P.S. Еще предлагаю убрать ненужные пробелы до и после @
Тогда вообще возможно можно будет обойтись одним лишь уменьшением интервала.
Инфа по анаморфу нужна, и та капля что не влезает, её тут запросто можно уместить, т.к. места и вариантов тут просто вагон. Это даже на глаз видно.
=============================================
Только сейчас заметил...а почему идет анаморфированное разрешение на 1ом месте?
Должно же быть "Реальное разрешение@Анаморфированное". Потому что логично именно так, фейковому разрешению не место в самом начале строки.

Сколько starsoft просил отщипнуть, столько и отрезал. Мне не жалко.
Разделяющий интервал не бесполезный, он необходим! Также как и отступы (по возможности) внутри поля спереди и сзади информации. Для хорошего зрительного восприятия, чтоб GUI гармонично выглядел. Отступы в полях Size и FPS имеют большой запас, их бы я и сократил (не до нуля конечно) в первую очередь и расширил левую колонку. Ну а уж если не хватит всё равно места, то уж тогда интервал между колонками стал сокращать, информация важнее. Если starsoft вдруг надумает изменять ширину, то надеюсь что он сделает чтоб всё было сбалансировано.

+ Предлагаю также в поле Size области General Information число, означающее размер файла в байтах (что в скобках) выводить с разделителями (пробелом) меду триадами разрядов, для лучшего восприятия. Запас места есть.
Т.е вместо (12586325147 bytes) сделать так: (12 586 325 147 bytes).

+ Ещё: в сокращённых единицах измерения байты обозначить заглавной буквой, т.е. B, MB, а биты - строчной (в общем как сейчас Mbps, kbps).
Чтобы путаницы не было.

+ А также добавить пробел между значением параметра и единицами измерения (там где отсутствует).

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


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

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

А я не пользуюсь (как показала практика) плагинами для просмотра видео. Недавний опрос Какой плагин просмотра видео вы предпочитаете использовать?, на который я наткнулся на сайте командера, в поисках того какие сейчас есть WDX плагины для видео (прежде чем закинуть удочку тебе) подтверждает, что и многие не пользуются. Хотя возможность м.б. полезна для просмотра кучи мелких видеофайлов в режиме Quick view. Но она никуда не денется, можно ведь плагины переключать, или их приоритет.

А информационным листер-плагином удобно было бы пользоваться, на мой взгляд, в том же режиме Quick view: в одной панели у тебя список видеофайлов (которые можно при необходимости отсортировать и отфильтровать средствами командера), а в другой инфо, наподобие как в GUI сабжа. Перемещаешься по файлам и смотришь параметры - на мой взгляд очень удобно. В GUI сабжа конечно тоже можно листать файлы, но он их как-то сам выбирает. В каком порядке. В командере всё гораздо удобнее было бы.



В общем так, но много исключений думаю. С камкордеров вроде бывают и в прогрессиве, встречал такое.
Всякие демонстрационные видео с дисков с разным типом расвёртки бывают.
Даже вот кроме вышеупомянутых двух типов MediaInfo различает такие подвиды как PAFF и MBAFF.
Опять же, как справедливо заметил xfiles, полно всяких "спутниковых и иных цифровых TV трансляций, которых с каждым днем становиться все больше и больше". Там тоже разные типы развёртки встречаются.
Не знаю, параметр Тип развёртки мне более интересен (другие параметры из подменю Additional Video Info мне не интересны, я даже не знаю что большинство означает) гораздо больше тех же чаптеров, которые меня не интересуют практически, даже я плохо представляю что это и зачем. Видимо метки в файле для позиционирования при просмотре на "железном" плэере, но я компьютером воспроизвожу. Тем не менее я не против наличия такого поля, пусть будет.
Но я бы сократил его на одну строчку ради параметра Тип развёртки.
Тем более я раньше предложил как сэкономить эту одну строчку, но её использовали для другого :-(.
Вообще у меня нет пока проблемы с размером GUI альтернативного.

Интервал между колонками просто пустое место, никак неиспользующееся и ничего не дающее. Даже если его убрать полностью, то того места, на котором находится надпись " FPS : " в качестве разделителя столбцов более, чем достаточно. А вот отступ в самих полях со значениями более полезен, именно поэтому я и предлагал уменьшать его во вторую очередь.


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


Это поддерживаю


Ага, и в итоге на одном и том же месте, например, имеем цифры 1920x1080 (и для настоящих 1920x1080 и для анаморфных 1440x1080). И если не приглядываться к продолжению @ то можно и не заметить анаморф. Нигде такой путаницы не встречал. Чем ТАК, уж лучше бы вообще разрешение анаморфа не отображалось.

На компьютере все видно, например, если сплиттер haali используется, то правой кнопкой мыши на его иконке в трее, и видны все названия глав. Честно говоря именно названия мне лично никогда не пригождались, а вот переход вслепую с одной главы на другую следующую/предыдущую гор. клавишами (когда главы есть) использую иногда.



Я тоже "за" сокращение на одну строчку поля чаптеров ради "Типа развертки".
Или может можно "вписать" окошко с "типом развертки" над переключателем "menu", а его сместить пониже.

Нет, какой-то интервал нужен всё равно.

Отступы нужны безусловно, но менее чем интервал. И в критическом случае я бы их уменьшил до нуля ради минимального интервала перед FPS :.
Обоснуй чем тебе отступы более важны. А так голословно.
На мой взгляд поле может обойтись и без отступов, хотя это и не есть гуд. Оно всё ж выделено рамкой.
А вот если перед FPS : не будет интервала, от он будет прилежать к левой колонке, а двоеточие после него будет создавать зрительный интервал - это будет очень плохо выглядеть. Нужен интервал ДО заметно больший чем двоеточие занимает.

Да вроде там то полно запаса.

Я не против разнести их в разные поля, но выходное (результирующее) разрешение вперёд (или выше).

А для чего это вообще? Для каких-то специфических видео с ярковыраженными главами?

Так будет нелогично, т.к. параметр относится к области Video Stream.

Отступы в самом поле, помогают легче различать цифры в этом самом поле, т.е. "FPS:цифры" не сливается в кашу, а значение "цифр" обрамлено пробелами с двух сторон.

Интервал ДО небольшой естественно нужен. Сейчас он наверно раз в 5 раз длиннее, чем нужно.

Суть не в том, чтобы что-то куда-то разносить, а в том, что оригинальное (реальное) разрешение должно быть ВСЕГДА в одном месте для ВСЕХ файлов (обычных и анаморфных), дабы не было путаницы и не приходилось каждый раз тщательно высматривать файл на предмет анаморфа, чтобы не ошибиться с разрешением из-за такой рокировки. А куда деть побочное фейковое анаморфированное разрешение не так важно, это доп. инфа, к тому же не особо существенная, т.к. показывает не реальный параметр файла, а "виртуальный". К тому же при анаморфировании из меньшего разрешения получается большее, и логично, что это должно идти справа налево, а не как сейчас - наоборот, от большего к меньшему.


Не полно. На моем последнем скриншоте не влезало 5,5 знаков. На урезании интервала между стобцами можно съэкономить 3-4 знака. Т.е. еще 2 знака надо выиграть за счет сокращения уже отступов. Не знаю, останется ли там место под доп. пробелы (если останется, я только "за" пробелы-разделители групп цифр)


Вообще говоря логичнее всего тут было бы в случае интерлейса дописывать к разрешению букву "i". По типу 1080i. Если такое возможно.
Потому что интерлейса все-таки относительно очень мало. И отдавать под него отдельное поле (которое в большинстве случаев а альтернативном GUI будет присутствовать и пустовать) - очень плохо.

Суть в том, что ты считаешь определяющим разрешение анаморфного кадра и соответственно сопостовляешь ЕГО с разрешением кадра в обычном фильме.
А я считаю определяющим в анаморфном видео (не с точки зрения разрешения как такового естественно, а с той позиции, какого размера кадр мы увидим в результате на экране) - выходное растянутое. И именно его и ставлю в соответствие. А разрешение анаморфного кадра считаю второстепенным параметром (в данном случае).
В этом мы и не сходимся, отсюда и спор.

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

Это будет очень закамуфлировано, не заметно.
Потом 1080i, 720i это уже стандартные обозначения для HD и не определяют разрешение по вертикали в чистом виде, а лишь тип развёртки. Если мы напишем, например 800i или 560i, это будет попахивать какой-то отсебятиной.
Кроме того MediaInfo различает, как я писал выше, и выдаёт в этот параметр всякие подвиды типа PAFF и MBAFF.
Мало может только среди фильмов, но не видео вообще, там много.
Пустовать не будет, там будет указан тип развёртки.

А в каких полях он отсутствует?

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

Мнения по разерам/положении полей я тоже понял, результат увидите в следующей версии в ближайшее время

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

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

В полях (общий и видео) Bitrate, но только когда параметр выражен в Mbps.
Когда в kbps - имеется.

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

Действительно! А я вот не замечал раньше, пока ты не сказал :-).

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

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

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

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

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

Кстати еще о разных "правилах". Раньше было правило что "биты" и "байты" в сокращениях различаются не строчностью буквы "B", а строчностью первой буквы абревиатуры (то есть к примеру Kb - kilobytes, kbps - kilobits per second). Сейчас эти принципы давно все забыли и делают кто во что горазд. А я старался придерживаться.

Это спасибо, исправлю. Прошляпил я этот момент.
Разделители цифр групповой разрядности числа в скобках тоже поставлю, но не пробелы, а то, что задано в системе в качестве "digit grouping symbol" - каждый настраивает систему под себя и этот символ тоже выбирает сам.

Да я не против, за. Хотел только принцип узнать.А Language как-то выбился из этой концепции?
Да, это будет более правильный подход.

Да в той же AviInfo когда добавил возможность читать язык потока (если такой чанк есть в заголовке потока), то его сделал тоже синим. Ну и тут по аналогии.

Ну и ну! Что это за правило, ты не перепутал ли чего?
Это значит "100 мегабит в секунду" будет - 100 mbps?
Это "милибиты" какие-то получаются!

У тебя кстати mbps с заглавной буквы прописаны, не особо придерживаешься ;-).

По той же причине, по которой там нет пробела после цифр - именно тут я не заменил то, что дает MediaInfo на то, что считаю правильным (в отличие от kbps - кстати тут тебя не смущает что первая буква маленькая?).

Хотя я не претендую на истину в последней инстанции (как и всегда) - имею право ошибаться как и любой человек

Обновление - версия 1.0.7 beta

Подробности вверху.

1)

Из этого я так понял, что реальное физическое разрешение теперь будет на положенном ему 1ом месте? Или я не так понял? В 1.0.7 оно по прежнему идет после анаморфного.

2) Заголовки Аудио, Сабов и Меню все еще не влезают 2х-значное количество дорог, 1-значное (растягивание GUI по ширине на это никак не влияет, да и к тому же ширина GUI и так достаточная, но появившаяся возможность сузить/растянуть по ширине GUI - интересная)

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

P.S. Придется пока откатиться на 1.0.6

2 19w85: Твой масштаб "пьёт мою кровь"... Хрен знает как учитывать этот гигантский масштаб при изменении размеров... просто "достаёт"... причем как я вижу расстояние между строчками большое, то есть сами поля неправильны по высоте, а положение их правильное...

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

Ну вот как знал что что-то да забуду... Не надо было релизить под вечер после рабочего дня...

Ну не знаю, в 1.0.6 была только проблема с шириной названий "аудио, сабы, меню". Всего одна проблема до практически идеального интерфейса. Теперь проблемы уже две - добавилась проблема с высотой. Надо же мне было ляпнуть на свою голову про "проблему" с центровкой в полях по вертикали (никто этого не видел, даже с930 не замечал, да и я только в последний момент заметил). Может можно просто откатить на то, как было в 1.0.6?


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

Правильное решение! ©

Замеченные глюки:
клавишами Grey +/- можно, как известно, масштабировать окно сабжа,
семь различных масштабов, пусть это х1, х2... х7, то
- при масштабах х6 и х7 некоторые заголовки полей "улазят за кадр";
- при масштабах х1... х4 поля по высоте наезжают др. на друга,
такого в прежних версиях не было. Похоже на то, что высота поля не масштабируется.

Предлагаю:
+ в General Information строку Title переместить с 4-й позиции на вторую,
+ а в Video Stream строки Frame size и Video codec - соответственно
на 2-е и 3-е места (соответственно их цветовому статусу ).

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


Друзья, по-моему вы что-то путаете:
анаморфный кадр - это как раз сжатый, искажённый (пусть преднамеренно),
а вы всё время анаморфным называете выходной, уже скорректированный до нужного Aspect Ratio.
Разрешение этого выходного скорректированного кадра и должно быть на первом месте,
как сейчас и есть.
Оно определяет реальное соотношение сторон в кадре!
А разрешение анаморфного кадра (сжатого) - это чисто технический параметр для искушённых.
Не нужно менять очерёдность следования разрешений!

Я лично против всего этого, нравится расположение именно такое как сейчас.


А мне вот это очень нравится, что как раз чередуются строки с колонками и за счет этого не сливается.


Какой еще сжатый кадр? Нигде никакого сжатия нету и быть не может.
Есть оригинальный кадр, и конкретное физическое разрешение этого кадра (допустим 720x576).
Для него задается определенное соотношение сторон, и из этого физического разрешения вытягивается анаморфный кадр с бОльшим разрешением с уже заданным соотношением сторон. Именно процесс вытяжения и называется анаморфированием.
Примеры:
720x576 (заданное соотношение 4:3) -> 768x576 (полученное путем вытяжение уже соответствующее соотношению сторон 4:3)
720x576 (16:9) -> 1024x576
Непонятно сколько можно жевать одни и те же термины и до сих пор в них путаться...если все еще непонятно - гугл в помощь (рекомендую). Или тебе просто нравится придумываться свою собственную терминологию/обозначения и называть белое чёрным? (по типу "оригинальный кадр=анаморфный кадр"). Не вижу смысла переливать из пустого в порожнее, когда всё 10 раз пережевано и принято решение.

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

Я же высказал свое мнение без привязки к терминологии - первым должен идти физический параметр - резолюция видео из файла (и к нему в скобках заданный в файле же аспект), а потом -> вычисляемый результат. Я именно так собирался заменить в итоге '@' на '->' чтобы обозначить источник и результат. Этот результат "реальным" можно назвать чисто гипотетически - если я растяну окно плеера, сохраняя аспект - то размер в пикселах станет бОльше, а я этого даже не пойму.
К тому же не знаю как вам, а мне при неплохой способности считать в уме все-таки как-то проблематично, увидев 2 трех- или четырехзначных числа, сделать какой-то вывод. Я смотрю на то, что сделал за меня комп - на аспект в скобках.

Расположение полей в блоке General - я согласен переместить Title под имя файла, так даже логичнее, а вот в Video - нет. Информация расположена не по цвету, а по смыслу - сначала общие параметры потока, потом кадра и количества кадров, а потом три параметра кодирования (кодек, битрейт и результирующее абстрактное 'качество' видео). А эстетика перемежения строк с колонками - как я и говорил про вкус и цвет у каждого своё.

С ошибками при масштабировании буду разбираться, идеи уже есть - надо пробовать...

Анаморфный, он и есть сжатый (по горизонтали). Преднамеренно искажённый (линейно), чтобы:
- в кинематографии уместить без чёрных полос широкоэкранный кадр на плёнку;
- в камкордере - на светочувствительный элемент, ПЗС или что там;
- а на DVD, чтобы вписаться в его формат кадра, опять же без чёрных полос.

Таким образом полнее используется площадь кадра плёнки или ПЗС-матрицы,
чем в случае с записью с чёрными полосами. И выигрывается разрешение.
В том числе используется эффект того, что у глаза разрешающая способность
по горизонтали ниже, чем по вертикали.
Я так себе представляю.

Я тоже когда изначально (перед тем как предложить негласно формат) думал про "стрелку",
правда она была влево направлена ;-).

Aspect Ratio не будет соответствовать разрешению за которым он следует.
Это будет вносить путаницу.

На мой взгляд - выходное разрешение, которое характеризует соотношение сторон в кадре и размер картинки, его я и сравниваю с другими рипами (разрешением др. рипов) например.
А сколько там пикселов в анаморфном кадре - дело второе.

А то что выходное разрешение "дутое", как 19w85 говорит, так разрешение большинства видеоконтента дутое, на мой взгляд, не соответствует реальной разрешающей способности.
Это я не понял про что. Если про то, что "Aspect Ratio не будет соответствовать разрешению за которым он следует" никто не заметит, то мне например, это сразу бросается в глаза (из практики говорю. Ну конечно не во всех случаях.) и будет ставить в недоумение. Хотя я плохо в уме считаю.
Про себя скажу. Я вперёд смотрю на разрешение и кодек (они у тебя и выделены зелёным как "важные"), а Duration, уж если мне нужно было, я в общих (General) параметрах пасмотрел. И "вес" видеопотока тоже уж дело второе.
Но главное, это опять я про себя говорю, т.к. 19w85 по-другому считает,
гляжу я на правую половину (Audio), там всё красиво, гармонично - колонки отдельно, строки отдельно.
А тут всё перемешано, глаза разбегаются.
Опять же с точки зрения композиции это неправильно, думаю.
(Композиция - в эстетическом смысле.)

Я так не считаю. Информация об имеющимся в файле видеопотоке это главное IMHO, а математически вычисленный из него результат - второстепенное.
Соответствие тут определяется стрелкой, а вне скобок и в скобках - два параметра файла.

Про то, что увидев на экране 1280х576 я не пойму какой тут аспект (только приблизительно из опыта), если не посмотрю на то, что в скобках.

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

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


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

Этот знак звучит как 'at' и означает принадлежность. Что в случае, когда после него идет результирующая резолюция, никак не логично. IMHO.

Хотелось бы знать где это употребляется (чтобы понять насколько это обычно) и как там форматируется информация.

Ну принадлежность также может обозначать, что разрешение стоящее после '@' относится к разрешению до '@' и что они взаимосвязаны.


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

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

Так может стОит так и сделать как в этом примере?
720x432@1024x432 (2.35:1)
Вроде как логично получается - физический первым, виртуальный вторым и объясняющий это аспект последним...
2 c930: Что думаешь?

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

А вообще это я не самый удачный пример привел, 1ый попавшийся, идеально и более правильно было бы вот так:
720x432 (2.35:1) @ 1024x432
До собаки идут физические параметры файла, оригинальное разрешение и аспект для данного файла. После собаки виртуальное разрешение, полученное путем перемножения "Оригинальной высоты*2.3x=ширина после анаморфирования".
Да и избавляться от пробелов теперь уже не имеет никакого смысла (когда под разрешение отдана целая строка), кроме как для ухудшения читабельности.

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

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

P.S. Что-то меня запарило обсуждать анаморф - возьму таймаут

Символ этот несёт смысл английского предлога at (или даже вроде как латинского).
По-русски читается как 'эт'. Помню даже в советском ГОСТе каком-то посвящённом печатным символам (либо ЭВМ) означался как "коммерческое эт". Это уж потом журналюги распространили его как собаку. Не они конечно этот жаргонизм придумали, он и раньше был наряду с другими названиями. Ухо или лягушка, я помню, тоже назывался.
Я предпочитаю называть 'эт'.

А переводится (передаёт смысл) в русском языке предлогами на, до, при, у, к, соответсвенно английскому предлогу.

Я когда предлагал изначально формат (не помню точно почему я стрелочку как у тебя отклонил, видимо как менее элегантный вариант) подразумевал at в значении при.
Но если ты хочешь сделать такой формат: 720x432@1024x432 (2.35:1), то я думаю не будет смыслового противоречия - разрешение 720x432 восстановленное до 1024x432.

Хи-хи, я думаю как и раньше:
1024x432 (2.35:1) @ 720x432
Но поскольку не могу вас двоих убедить, готов смириться с таким вариантом (Но не согласен!):
720x432 @ 1024x432 (2.35:1)

Такой вариант считаю неприемлемым вообще (по причине возможных недоразумений и путаницы):
720x432 (2.35:1) @ 1024x432

Обновление - версия 1.0.8 beta

Подробности вверху.

Первые заметки:
+ глюк с наездом полей по вертикали друг на друга при уменьшении масштаба исчез,
- толшина межи правда между полями при изменении масштаба не постоянна, а меняется.
Но не пропорционально высоте поля, а как-то то больше, то меньше.
- Глюк с заездом названий полей "за кадр" при масштабах х6, х7 остался.
- Глюк: на масштабах х4... х7 глючит растягивание окна по горизонтали,
нельзя сузить окно уже определённой ширины. Возможно в предыдущих версиях тоже был.
- Ниспадающие боксы (Аудио, Меню, Субтитры) вроде стали уже по сравнению с предыдущей версией 1.0.7 и не всегда вмещают текст полностью. Наверное 19w85 будет ругаться.
- GUI иногда при масштабировании или при нажатии Page Up/Down самопроизвольно сворачивается в таскбар.

Предложение
- Чаптеры, я думаю, лучше выравнивать не по центру, а по левому краю. Будет читабельней.

Вопросы
- В какой последовательности сабж перебирает файлы при нажатиях Page Up/Down?
- Где портабельный сабж хранит настройки (типа Always on top, Save window..., Auto check..., тип GUI)?

Просьба
Нельзя ли сделать опционально разрешение на перебор по Page Up/Down файлов в других видеоконтейнерах. А именно по расширению например AVI, FLV, MP4, MPEG, MPG, M2TS, TS, TP, RM, QT, MOV, ASF, WMV, 3GP, OGG, VOB и т.п.

Ну и что? Положение постоянно на форме, а размер зависит от масштаба. И, поскольку размеры целочисленные, а масштаб дробная (относительная) величина, то и результат вычисления может быть +/- 1 пиксел. Что может вылиться и в 2. Только почему это должно волновать? Масштабирование предназначено для одноразовой настройки проги "под себя", а не для игрушек "туда-сюда". IMHO.

У меня этого не наблюдается при системном масштабе 100%. Какой системный масштаб у тебя?

Есть минимальный размер, меньше которого нельзя сузить. Этот минимальный размер тоже зависит от масштаба. Может и есть глюк - я не замечал. Проверю.

Я уже говорил в обсуждении AviInfo что это уже от меня не зависит. После нажатия один раз надо дождаться пока появится окно, иначе следующее нажатие попадет в окно, которое ниже (или на десктоп), а появившееся но потерявшее фокус окно MKInfo оказывается свернутым в таскбар. Библиотека MediaInfo работает гораздо медленее чем AviInfo, и вероятность что "быстрые пальцы" приводят к описанному эффекту гораздо выше.

Пробовал, не понравилось. Могу для эксперимента вернуть.

В алфавитном порядке имен файлов.

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

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

Глюк: при прокрутке чаптеров (что стрелками, что слайдером без разницы) они превращаются в "кучу-малу". Могу скриншот сделать, если надо.
В предыдущих версиях такого вроде не было. Попробовал на 1.0.6 - там всё нормально.

Ясно, просто в глаза бросилось. Фича не критичная, пусть так.
У меня всё по дефолту. Но думаю дело не в бобине.
Я видимо не разобрался. Это не глюк, а фича, связанная с появлением в предыдущей версии возможности менять ширину GUI. При сужении окна более какого-то предела все заголовки полей начинают уезжать влево "за кадр", а параметры соответственно вправо.
А я смотрел при какой-то определённой ширине окна и "заезды" наблюдались при самых больших масштабах.
Так что вопрос снимается.
Попробуй помасштабировать окно в значительных пределах при масштабах х4... х7 и отпишись. У меня глючит.
Соответствующие разряды значений времени будут один под другим и тексты начинаться с одной позиции.
По-моему должно быть всё гораздо читабельней.
Давай для эксперимента в следующей бете попробуем.

А нельзя ли настройки хранить в INI-файле в каталоге программы? Для чего их хранить там в реестре?
Это повысит портабельность! Параметры не будут теряться.
Можно б было в нём (INI-файле) сделать скажем раздел, где осведомлённый пользователь вручную бы прописал нужные расширения файлов на которые бы распространялись клавиши Page Up/Down. А в GUI бы ничего не было на эту тему.

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

1.0.7 я фактически не пользовался, поэтому сейчас сравнивал 1.0.6 и 1.0.8

Вот что не понравилось:

Ужасно не нравится, что теперь выделены цветом названия блоков "General Information", "Video Stream" и т.д.
Теперь пестрит от чрезмерного выделения цветом. Выделять только тех. параметры файла - было более правильным решением.
===============================================
Не очень нравится, что переместили строку "Title" в блоке "General Information". Раньше часто пустующая строка "Title" очень удачно отделяла строку с продолжительностью и битрейтом от строки с энкодом. Теперь всё сливается, т.к. отделяющей строки теперь нет, и цветового выделения тут тоже нет.
===============================================
Ну и всё-таки ИМХО зря остановились на таком варианте:

Чередование физических и виртуальных параметров.
В моем варианте (как например, тут) чередования не было + первая часть была бы всегда одинаковая для всех файлов (обычных и анаморфных): физическое разрешение (аспект)



Зачем было в последний момент перемещать соотношение сторон в самый конец строки - непонятно (изначальное ведь планировалось только поменять местами разрешения). Теперь по быстрому не посмотришь разрешение-аспект из-за встрявшего по середине "виртуального" разрешения. Море времени потраченное на обсуждение анаморфа - потрачено впустую Было запутанно, стало неудобно. Шило на мыло поменяли.
===============================================

Понравилось:
++Что теперь влезают заголовки Аудио, Сабов и Меню (даже запас очень огромный остается, особенно у сабов, вот у них чуток уменьшить наверное даже неплохо было бы )
http://s005.radikal.ru/i212/1109/5d/24a3514340b0.png
http://i061.radikal.ru/1109/ee/04f9df779f6a.png

+Строки по высоте теперь вроде умещают текст (но как-то совсем впритык), но они по высоте теперь значительно ниже (и как-то теперь очень "тесно" это смотрится на мой взгляд), чем были в 1.0.6.
Высоту строк хотелось бы нечто среднее, между тем что было в 1.0.6 и стало в 1.0.8
===============================================

Это точно, авиинофо в этом плане на данный момент в разы стабильнее.


Категорически против такого! Мне бы наоборот лучше по правому краю, ближе к центральной оси, но уж никак не левее, чем сейчас.


Оно бывает и после 1ого нажатия сворачивается.


Было бы интересно. В контекстном меню-то mkinfo я уже давно прописал для всех мультимедиафайлов, а вот "перебор по Page Up/Down файлов в других видеоконтейнерах" не сделать.

Ха, а я и не заметил. При моём размере шрифта (дефолтный) не особо и заметно.
Но я в принципе за нововведение.
Да, интересно.
А посмотри на мой скриншот.

Даже задняя скобка не влазит на некоторых масштабах GUI.
Посмотри на скриншот выше, где чаптеры содержат текст разной длины. Тогда может ты согласишься со мной и поймёшь о чём я.
И у меня тоже так бывает, что даже после первого.

Вот глюк какой у меня при прокрутке чаптеров:

Ни у кого такого нет? Исходный скриншот выше.

Вот видишь, ты даже не заметил, но все равно естественно "за". Я в этом не сомневался. Благодаря твоим "замечательным предложениям", интерфейс из комфортного (1.0.6) потихоньку из-за этих мелких "незначительных" изменений и перестановок превратился для меня в дискомфортный (1.0.8). И если бы на 1.0.6 влезали поля, я бы на ней так и остался...


Всё хорошо. Не соглашусь.


У меня тоже есть такое.

"естественно", что ты в это вкладываешь? Заголовки слегка "оттеняются" тоном. Совсем чуть-чуть (поэтому сразу и не заметил), и это именно никакой "пёстрости", как ты сказал, на мой взгляд не добавляет.
Мне понравилось вобщем.

А как ты относишься к идее INI-файла (выше я писал). Можно было б подбить автора на некоторые индивидуальные настройки и нивелировать часть разногласий таким образом.

Типа так:

Куда-то собеседники пропали.
А я вот глюк нашёл в классическом GUI.
На некоторых файлах комбобоксы закрываются полями Language.
Похоже это происходит когда в соответствующих streamах отсутствует поле Title.

Мысли ни о чём:
вот тут написано, что видеоформат WebM
основан на подмножестве медиаконтейнера Matroska.
Сайт YouTube.com уже поддерживает данный видеоформат.
Вот пример я выложил тут
(выступление Mylene Farmer 9 июня 1986 г. в летнем туре Podium Europe 1 по Франции, снято в Майенне).

Никуда не пропали, тута Всему своё время...

Если его в нативном виде поддерживает библиотека MediaInfo - так что за проблемы, добавлю в список расширений файлов и все дела.

Насчет настроек... Вот 3 человека обсуждают, а мнений на десятерых хватит. Неужели все живут в моей стране

Я не большой любитель INI-файлов по тем же причинам, по которым им на замену когда-то появился реестр. Во-первых, это лишний файл. Во-вторых, это обычный текстовый файл, который легко испортить даже не прилагая усилий, просто случайно открыв его в блокноте. Он никак не защищен "от дурака", написать в любой строке бредовый параметр пара пустяков. Реестр тоже не слишком закрыт, но там а) нельзя вписать параметр несоотвествующено типа; б) Нужный блок параметров еще нужно найти и в) в итоге добраться до параметров все-таки можно только целенаправленно, а не случайно.

Я могу сделать INI-файл опциональным, то есть то, что сейчас храниться в реестре (положение окна, всегда вверху и прочая лабуда), там и оставить. Но для всяких "недокументированных" возможностей сделать через проверку на наличие INI-файла и анализ его содержимого. Тогда тот, кого все спорные вещи не волнуют, никогда о них и не узнает. А для "очумелых ручек" не будет проблем сделать свой или скачать шаблонный INI и отредактировать. Одобрямс?

А вот тут, извиняюсь, ничего менять не буду. Этот цветовой набор есть во всех моих информационниках и таким его и оставлю. Этого не было в первых версиях просто потому что забыл. Темно-синий цвет уж никак не "пестрит" форму IMHO. Могу только сделать его еще чуток темнее.

Я лично двумя руками "за"!


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

И чем темнее, тем лучше. А еще лучше тогда в ini добавить возможность задать цвет (черный был вообще идеальный, не отвлекал на себя внимания и совершенно не мешал, при этом все отлично читалось)

И я кстати, не понял что случилось с высотой строчек? (1.0.6->1.0.8)
Центрирования по вертикальной оси внутри полей так и нету, зачем тогда так сильно уменьшилась высота строчек и почему? Хочется бОльшей высоты, чем сейчас.

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

Предлагаю реестровые опции продублировать ключами в INI-файле.
Для дефолтного юзера значения будут браться из реестра, а если в каталоге программы присутствует INI-файл, то из него (если там есть дублирующие ключи). Т.е. ключи сделать приоритетными.

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

И какой в этом смысл? Реестровые опции меняются интерфейсом программы, а не руками - это опции в меню. И какой смысл их менять если они вручную заданы в INI? Не вижу логики. И вообще, к примеру, откуда ты знаешь что прописать в неких полях, которые задают координаты положения окна - пиксельные координаты или логические единицы?
Короче - в реестре опции, которые не только читаются программой, но и меняются ею же. А INI редактируется руками, прога только берет оттуда параметры.

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

Да уменьшил я высоту чтобы, увеличив видеоблок на 1 пункт (для Scan Type), не урезать остальное, а вписаться в нормальную высоту. Я не понял что тебе не нравится? На твоих же скриншотах последней версии не вижу никаких недостатков по высоте строк.

Ну я же не знаю состав параметров, какие в реестре хранятся.
А смысл был такой - для мобильности. Чтобы при запуске программы в разных установленных на одном компутере ОС или запуске со съёмного носителя (флэшдрайва) на разных компутерах (там утилита м.б. и не установлена. И зачем на чужом компе я буду реестр загаживать. Или менять их, если на чужом компе есть такие) не нужно было опции подправлять.
Например, пусть так: если есть INI-файл в каталоге программы, то прога пусть всё хранит и берёт из него, а реестр по боку (для осведомлённых юзеров с "очумелыми ручками"), а если нет, то из реестра.
А на счёт всяких координат и пр. не очень прозрачных параметров для юзера, то мне и нет нужды в общем случае их вручную задавать, программа их будет прописывть. Лишь бы они были "всегда со мной".
Ну примерно так как-то.

2 c930:
Во-первых, параметры, хранящееся в реестре, ничего не портят и никому не мешают. Они в апликативной ветке, к системе не имеют отношения. А то, что имеет - регистрация компоненты, как раз и уйдет из реестра при номальном закрытии аппликации.
Во-вторых, часть параметров просто нельзя переносить с компа на комп - к примеру при разных резолюциях экрана координаты окна просто могут закинуть окно за пределы видимой области - и что делать тогда? Лезть руками в INI?
В-третьих, это просто удобно, что на этом же компе прога поднимется с тем, что для нее в последний раз сделали, а не с тем что делали на другом компе с его особенностями и резолюциями.
Да и параметров то там кот наплакал, чего вообще о них говорить.

"Огласите весь список, пожалуйста!"

А в реестр заглянуть слабо?

Using alternative GUI y/n
Always on top y/n
Auto check update y/n
Save window position y/n
Font size
Window size for regular GUI
Window size for alternative GUI
Window X position on screen
Window Y position on screen

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

А эти, например, почему нельзя? Не вижу причины.
Ну так это и без переноса такая ситуация тогда может возникнуть. Сменил я в той же винде видеорежим с понижением разрешения экрана - и привет!
Нужно стало быть при запуске проверять текущее видеоразрешение. И в критической ситуации позиционироваться скажем в центр экрана.
Или вот как в вышеупомянутом Total Commanderе сделать. Он кстати все настройки хранит в INI-файле (а параметров там может быть с туеву хучу) и нет проблем.
Параметры зависящие от разрешения экрана он хранит в подразделах типа [800x600], [1024x768], [1920x1080] и т.п. Для каждого свои. Эти разделы добавляются автоматом по мере возникновения ситуации. Ты вроде пользуешь его, нажми F1 -> INI-File settings: wincmd.ini.

А что это за параметр Font size? Масштаб GUI?
Да, удобно. Приду я в гости к 19w85 чай пить. Его настройки мне допустим не нравятся. Я с флэшдрайва свою запущу. А она в его реестре поправит параметры. Он меня потом убъёт.

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

Мне льстит сравнение с ТС - это моя любимая программа с первой его версии. И одна из очень немногих, которые хранят данные в INI (и при этом еще и позволяют прямо из меню открыть их в блокноте и менять). Но мои утилиты - не ТС все-таки, чтобы так уж придирчиво относиться к параметрам, еще и под разрешения их хранить - это перебор

Да

Ну надуманный пример. Ты со своим ТС на флешке ходишь в гости?