AVF metadata format for SIDE3, etc

[flashjazzcat]

I'm revamping the SIDE3's PDM player and adding video playback support, and since this will require a redesigned file format for video files (there being no need for padding bytes in the audio/video data; I'll write a converter for this and provide instructions for encoding videos from scratch), I thought it might be an opportune moment to add a file header with metadata rather than just persist with binary blobs and inferring all information from the filename alone. I'm thinking PAL/NTSC encoding, bitrate, extended title information, genre, etc. There are no particular alignment issues, so we can use as much or as little space as required for the metadata header.

 

If people have no suggestions, I'll go ahead and design it to my own specifications, but I thought I'd just throw it out there for discussion.

[Beeblebrox]

Nice one. Meta data wise, data on video file duration is something I assume is going into the metadata? Would be cool if, like the online Fujiconvert, there was an online converter. Not sure if that is a plan. 

 

Either way, thanks for undertaking this - I know it's a big coding job. 

[flashjazzcat]

13 minutes ago, Beeblebrox said:

Meta data wise, data on video file duration is something I assume is going into the metadata?

I figure run-time (and thus a time position indicator) can be cooked up from filesize divided by bitrate, but yes: if it's common to include runtime data in such headers, why not.

15 minutes ago, Beeblebrox said:

Would be cool if, like the online Fujiconvert, there was an online converter.

My coding skills beyond 6502 assembler extend to C and pretty much no further, so perhaps someone else can take my converter and web-ify it when the time comes.

16 minutes ago, Beeblebrox said:

Either way, thanks for undertaking this - I know it's a big coding job. 

Been wanting to attack this task for some years, but lack of time, etc.

[+CharlieChaplin]

@jhusak worked on an improved AVF player and a new file format a few years ago. Do not know for sure, if he also implemented a header or not. Find attached what I have available (think I downloaded it from atarionline.pl)...

 

The new file format will (however) only work with his new player and he wanted to further improve it - but nothing else was released until today. Don't know if he stopped this project or if its "simply" lack of time. Afair, the new player(s) can also play the old AVF format (but the old player cannot play the newer format).

 

Maybe you can take a short look.

 

P.S.: - AVFPlay is for playback with Pokey sound, all other AVF players are for playback with Covox sound (AVFPlay2 uses Covox at D2xx, AVFPlay5 uses Covox at D5xx, AVFPlay6 uses covox at D6xx and AVFPlay7 uses Covox at D7xx). No matter if Pokey or Covox, sound in AVF is mono only. Short textfile included that explains the extra keys (Start, Select, Option, ESC) in use.

 

 

 

new_AVF_players.zip new_AVF_Files.zip

[+CharlieChaplin]

On my big wishlist would be a completely new AVF format using Gr. 10 (luma) + Gr. 11 (col) and the HIP/RIP  GTIA-shifting trick, so we end up with 160x200 pixels resolution (thanks to GTIA-shifting) and 8 lum x 16 col = 128 colours. What, only 128 colours, not 256 ? Yes, but we have 4 times higher resolution, since Gr. 9+11 has only 80x100 pixels resolution.  phaeron said HIP (greyscale only with 160x200 pixels) would be doable, so I guess (or better wish) this Gr. 10+11 would also be doable and someone would finally do it...  

 

HIP/RIP with GTIA-shifting: (160x200 or up to 160x240 pixels resolution)

Gr.8

Gr.10

Gr.8

Gr.9

Gr.8

Gr.10

Gr.8

Gr.9

etc.

 

my Gr. 10+11 wish with GTIA-shifting (160x200 or up to 160x240 pixels):

Gr.8

Gr.10

Gr.8

Gr.11

Gr.8

Gr.10

Gr.8

Gr.11

etc.

 

Gr. 10 gives us 8 lumas, Gr. 11 gives us 16 colours + the overall/base luma (which could be used to set the darkness or brightness of the picture). Gr. 10 is required for the GTIA-shifting (higher resolution), which afaik happens when switching from Gr. 8 to Gr. 10...

 

 

 

[Mathy]

Hello Jon

 

Don't all these AVF players load data in a fixed block size?  (512kB, 1MB or 2MB?)  If that is true, you could use one such block (the first one?) for the header.  That should be more than enough.

 

One/first block would, if it's not skipped while playing, only be displayed for 1/50th or 1/60th second.  That's shorter than the blink of an eye.

 

Sincerely

 

Mathy

 

[flashjazzcat]

15 hours ago, CharlieChaplin said:

Maybe you can take a short look.

Thanks so much.

14 hours ago, CharlieChaplin said:

On my big wishlist would be a completely new AVF format using Gr. 10 (luma) + Gr. 11 (col) and the HIP/RIP  GTIA-shifting trick, so we end up with 160x200 pixels resolution (thanks to GTIA-shifting) and 8 lum x 16 col = 128 colours. What, only 128 colours, not 256 ? Yes, but we have 4 times higher resolution, since Gr. 9+11 has only 80x100 pixels resolution.  phaeron said HIP (greyscale only with 160x200 pixels) would be doable, so I guess (or better wish) this Gr. 10+11 would also be doable and someone would finally do it... 

It's going to be encoding of the source material for anything but the current 80x96 pixel format which will probably prove most challenging for me, but there is no reason whatsoever why different software graphics modes can't be used in accordance with the playback format description in the file header.

18 minutes ago, Mathy said:

Don't all these AVF players load data in a fixed block size?  (512kB, 1MB or 2MB?)  If that is true, you could use one such block (the first one?) for the header.  That should be more than enough.

 

One/first block would, if it's not skipped while playing, only be displayed for 1/50th or 1/60th second.  That's shorter than the blink of an eye.

Yes - in this case, we'll be pulling in a whole cluster at a time (so multiples of 512 bytes), but data alignment doesn't really matter since video and audio data will be buffered ahead. Header will never be mistaken for AV data, and we can have a header size byte in the first sector which just tells us the size of the metadata area and thus how much data to skip when commencing buffering and playback.

[+CharlieChaplin]

Jakub Husak's AVF players on his Github page:

https://github.com/jhusak/avgcart_avfplay

(just so you know.)

[+MrFish]

KODI (open-source home-theatre software) uses NFO (info) files with simple XML for movie metadata. I'm not suggesting use of separate files or XML; but... you might want to use some of the standard fields they use (or at least get some ideas for what might be useful), since these are based on some more-universal standards for movie metadata.

 

Here's their standard movie template.

 

If you want explanations for any of the tags (and more movie tags that are accepted by KODI), you can see them here: KODI - NFO Files / Movies

 

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<movie>
    <title></title>
    <originaltitle></originaltitle>
    <userrating>0</userrating>
    <plot></plot>
    <mpaa></mpaa>
    <uniqueid type="" default="true"></uniqueid> <!-- add a value to type="" eg imdb, tmdb, home, sport, docu, see sample below -->
    <genre></genre>
    <tag></tag>
    <country></country>
    <set>
        <name></name>
        <overview></overview>
    </set>
    <credits></credits>
    <director></director>
    <premiered></premiered> <!-- yyyy-mm-dd -->
    <studio></studio>
    <actor>
        <name></name>
        <role></role>
        <order></order>
    </actor>
</movie>