Page 1 of 2

pixel heigh definition criteria

Posted: Mon Dec 12, 2011 10:20 am
by samu-mac
Hello

i would like to suggest a smart criteria that lack ATM (i may be wrong but i looked for that everywhere)

would be cool if we can also can see and use the pixel heigh of video... 720, 540, 1080 etc...

actually i saw only video ratio.. but it does just say if is 4:3 or 16:9 and it's different from what i'm askin


i think would be really easy to get this information out from the video and add it :)

really thanks in advance

Cheers

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 8:24 am
by Nora
Not something we considered before but thanks for the idea. In the next version you can name two custom fields "Video Height" and "Video Width" and the program will add the information to the fields when you import a movie. (This will not work retroactively for movies already imported. For those you'd have to drag the movie files once more over the DVDpedia icon.)

If you want to try it out before the official release, download the beta.

As long as your Finder knows the sizes, they'll be imported along with the rest of the information.

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 10:36 am
by samu-mac
OH cool!

Damn about those already added, will be a way or a method to save the cover\informations\rating but also add the new details? maybe with an external database program?

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 10:50 am
by samu-mac
Nora wrote:
If you want to try it out before the official release, download the beta.
i downloaded and added a new film but cant manage how get this out

As you have 2 minutes help me please^^

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 11:41 am
by Nora
What exactly is the problem so I can help? Nothing happens when you drag the movie over the DVDpedia icon? Or the pixel data isn't imported? (In our tests here we couldn't really try this since none of our files have the pixel size included, i.e. it's not displayed in the Finder for us and hence can't be imported.)

Regarding your other question about movies added earlier, when you drag the movie and it finds a duplicate in DVDpedia (say no to importing duplicates) it'll add any new information it finds for those entries already present, but only if the fields are empty. Nothing will be overwritten.

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 12:03 pm
by samu-mac
Nora wrote:What exactly is the problem so I can help? Nothing happens when you drag the movie over the DVDpedia icon? Or the pixel data isn't imported? (In our tests here we couldn't really try this since none of our files have the pixel size included, i.e. it's not displayed in the Finder for us and hence can't be imported.)

Regarding your other question about movies added earlier, when you drag the movie and it finds a duplicate in DVDpedia (say no to importing duplicates) it'll add any new information it finds for those entries already present, but only if the fields are empty. Nothing will be overwritten.
I imported a film but i cant get out the pixel height ( using beta version ) i tried rename a custom "Video Height" but still nothing.

Dnno, maybe my files does not have the pixel height information included? Infact i dont see it in the finder, but i dont see neither subtitles or languange so i supposed DVDpedia can go deeper in the file to get informations that any mediaplayer can extract

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 12:13 pm
by Nora
If the pixel info isn't displayed in the Finder it's not part of the file unfortunately (as far as I know). Other info such as language isn't displayed in the Finder because there are no fields for it in the Finder display. The information for those fields is in the same location as the size would be though.

We can look at having the program dig deeper into the file for information in the future but with the number of movie file types available this is not going to be a quick change.

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 12:36 pm
by samu-mac
Nora wrote:If the pixel info isn't displayed in the Finder it's not part of the file unfortunately (as far as I know). Other info such as language isn't displayed in the Finder because there are no fields for it in the Finder display. The information for those fields is in the same location as the size would be though.

We can look at having the program dig deeper into the file for information in the future but with the number of movie file types available this is not going to be a quick change.
Ok thanks for infos, i'll do further investigation and maybe if i find a way using a third part program to add infos to the file to make DVDpedia able to read them i will write in this topic :)

thanks

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 3:29 pm
by sjk
Nora wrote:Not something we considered before but thanks for the idea. In the next version you can name two custom fields "Video Height" and "Video Width" and the program will add the information to the fields when you import a movie.
Is there a list of custom fields that DVDpedia treats specially like this? I couldn't easily tell by looking at text strings near where those two appear in DVDpedia and Pediabase binary files.
If you want to try it out before the official release, download the beta.
What happened to beta version numbering for easier identification purposes, e.g. referenced in forum topics? :)

Re: pixel heigh definition criteria

Posted: Wed Dec 14, 2011 4:41 pm
by sjk
Nora wrote:If the pixel info isn't displayed in the Finder it's not part of the file unfortunately (as far as I know).
I've never noticed kMDItemPixelHeight, kMDItemPixelWidth metadata (displayed as Dimensions under Finder > Get Info / More Info), and other related metadata set for video media in MKV containers (with .mkv filename extensions). It's often there with more common QuickTime-compatible file/container formats, including those converted from MKV (e.g. "passthrough" saving them as .mov files using QuickTime 7 Pro or MPEG Streamclip with Perian installed). Spotlight is aware of "Matroska video" but OS X doesn't natively support it.
Other info such as language isn't displayed in the Finder because there are no fields for it in the Finder display. The information for those fields is in the same location as the size would be though.
I've seen English appear in kMDItemMediaTypes (a specific video metadata attribute key) for QuickTime videos, but maybe kMDItemLanguages (a common metadata attribute key) is a better choice (if any).
We can look at having the program dig deeper into the file for information in the future but with the number of movie file types available this is not going to be a quick change.
Utilizing MedaiInfo for that digging could probably be the easiest, most obvious choice.

Re: pixel heigh definition criteria

Posted: Thu Dec 15, 2011 2:38 pm
by Nora
Is there a list of custom fields that DVDpedia treats specially like this?
Apart from the IMDb options for some special fields (Cinematographer, Composer, Metacritic and soon Color) these are the only other options at the moment. They'll be included in the Help file for the next official release.

Beta version numbering is coming back, Conor's still trying to tie it in with his version control system so it'll be automatic in the future.

@samu-mac: sjk is correct about the OS X Finder metadata. But hopefully this will only get better as Lion matures.

Re: pixel heigh definition criteria

Posted: Thu Dec 15, 2011 3:09 pm
by samu-mac
sjk wrote: Utilizing MedaiInfo for that digging could probably be the easiest, most obvious choice.
this program is for windows only, anyway through this i can add the pixel heigh informations to my files?
Nora wrote:
Is there a list of custom fields that DVDpedia treats specially like this?

@samu-mac: sjk is correct about the OS X Finder metadata. But hopefully this will only get better as Lion matures.
Ye i think ive understood what sjk wrote, but so, we cant do anything if lion does not support MKV still?

Re: pixel heigh definition criteria

Posted: Thu Dec 15, 2011 5:32 pm
by sjk
Nora wrote:Apart from the IMDb options for some special fields (Cinematographer, Composer, Metacritic and soon Color) these are the only other options at the moment. They'll be included in the Help file for the next official release.
I remember Episode Name being added as a special custom field when support for importing EyeTV recording packages was added. The Import entries help (under EyeTV) says:

- If you have custom field titled 'Episode Name', the import will fill in that information for you.

Still works that way. Episode (which used to be custom?) and Season, valid EyeTV metadata, are non-custom fields in 5.0:

- Added 4 new fields, specifically for TV: Season, Episode, Creator and Series.

DVDpedia uses Episode and ignores Season, if either exist, with EyeTV importing. I'll post some suggested improvements for EyeTV importing in a separate topic.
Beta version numbering is coming back, Conor's still trying to tie it in with his version control system so it'll be automatic in the future.
Cool. Thanks for the update.

Re: pixel heigh definition criteria

Posted: Thu Dec 15, 2011 5:53 pm
by sjk
samu-mac wrote:
sjk wrote:Utilizing MedaiInfo for that digging could probably be the easiest, most obvious choice.
this program is for windows only, anyway through this i can add the pixel heigh informations to my files?
There are GUI and CLI versions for OS X.
Ye i think ive understood what sjk wrote, but so, we cant do anything if lion does not support MKV still?
To automatically populate the new Video Height and Video Width custom fields for MKV video imports, Bruji would have to add support (e.g. with MediaInfo) for obtaining/using that metadata since OS X doesn't provide it natively.

Which subset of the vast amount of audio/video metadata is reasonable for DVDpedia to directly import/support is debatable. :)

Re: pixel heigh definition criteria

Posted: Fri Dec 16, 2011 1:17 pm
by Nora
@sjk: You're right, I forgot about the EyeTV import. That probably needs some updating in the future, we'll take a look at that.