Каскадный · [ Стандартный ] · Линейный+ Еще один информационник - MKInfo, (обновлено 3 июня 2012 г., версия 1.0.12 beta)

[starsoft]

Можно отцентрировать по вертикальной оси значения во всех полях?

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

Цветовая дифференциация по важности?

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

источник экономии места

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

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

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

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

[c930]

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

Да я не против, за. Хотел только принцип узнать.

(в этой проге это titles)

А Language как-то выбился из этой концепции?

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

Да, это будет более правильный подход.

[starsoft]

А Language как-то выбился из этой концепции?

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

[c930]

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

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

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

[starsoft]

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

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

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

[starsoft]

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

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

[19w85]

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

1)

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

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

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

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

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

[starsoft]

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

да и к тому же ширина GUI и так достаточная

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

В 1.0.7 оно по прежнему идет после анаморфного

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

[19w85]

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

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

да и к тому же ширина GUI и так достаточная

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

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

[c930]

версия 1.0.7 beta
+) Альтернативный GUI может менять размер по ширине

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

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

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

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

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

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

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

[19w85]

Предлагаю:
+ в 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 раз пережевано и принято решение.

[starsoft]

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

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

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

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

[c930]

Какой еще сжатый кадр?

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

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

'->' чтобы обозначить источник и результат

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

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

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

первым должен идти физический параметр

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

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

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

Это я не понял про что. Если про то, что "Aspect Ratio не будет соответствовать разрешению за которым он следует" никто не заметит, то мне например, это сразу бросается в глаза (из практики говорю. Ну конечно не во всех случаях.) и будет ставить в недоумение. Хотя я плохо в уме считаю.

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

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

[starsoft]

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

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

Это я не понял про что.

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

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

[19w85]

Я именно так собирался заменить в итоге '@' на '->' чтобы обозначить источник и результат

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

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

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

[starsoft]

А @ нельзя оставить?

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

анаморф через нее обычно обозначают

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

[19w85]

А @ нельзя оставить?

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

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

анаморф через нее обычно обозначают

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

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

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

[starsoft]

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

[19w85]

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

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

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

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

@ 1024x432

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

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

[c930]

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

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

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

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

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

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

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