Feature Suggestions Regarding Automatic Filename Generation

[Nuihc88]

As i've been doing a lot of test encodes lately, which mostly just consists of tediously copy-pasting Encoding settings and filesizes to text files for comparison in WinMerge, i've come up with some ideas that would make this sort of thing a whole lot faster...

1. Support adding metadata like Filesize, Bitrate, PSNR, SSIM & Encoding settings to automatically generated filenames.
   • Since adding Encoding settings could easily result in a filename that's way too long, also allow blacklisting of user specified / redundant text strings like so:
   Blacklist:
   cpuid=*; frame-threads=*; numa-pools=*; no-pmode; no-pme; psnr; ssim; log-level=2; input-csp=1; input-res=1920x1080; interlace=0; total-frames=0; level-idc=0; high-tier=1; uhd-bd=0; ref=6; no-allow-non-conformance; no-repeat-headers; annexb; no-aud; no-hrd; info; hash=0
   • With '*' being a wildcard and ';' acting as separator. Thus user would be able to copy-paste their baseline settings here and have the filename only include the changed settings.
   
   
2. When specified, use automatically generated filenames also for intermediate Video, Audio & Subtitle tracks, each with their own Filesize(in bytes), bitrate(in Kbps), etc. metadata; renaming can be done once encoding is finished.
   
   
3. The two suggestions above would make this almost obsolete, but allowing for serialization of filenames, where for example: 'test#{2}' would become 'test#01' unless it already exists, in which case it'll become 'test#02' as opposed to just replacing the older file. This would help avoid accidental overwrites. I haven't really given much thought to whether '{#}' would be a good markup (there could be more commonly used alternative), but the general idea is to allow for padding with zeros to a specified length.
   
   
4. To keep things cleaner, I've been using a simple trick to do my encodings inside a subfolder of the source file's directory by setting 'enc\' as prefix for the filename. However .chp & .xml files are still being created inside the source file's folder. Perhaps there is a reason why these need to be there during encoding, but moving or deleting them automatically after encoding would be helpful, especially since a new one gets created every time the file is encoded, thereby making the folder slower to navigate and easier for user to accidentally delete something they shouldn't. EDIT: This is about adding full support for dynamic destination directories, not about improving or fixing an accidental 'feature'.
   

PS. I'm gonna see if i can create a poll on this new forum system to see whether these ideas have any traction within the userbase.

[Selur]

My two cents:
Regarding 1.:
This request should go to the x265 developers not me.

Regarding 2:
Not going to happen. Intermediate files did at one point contain lots of meta data which causes lots of problems on Windows due to lack of UTF-8 support through a bunch of tools and some Windows combinations. To avoid those problems Hybrid now should use generated names based on the job ID and this is the way it will stay.

Regarding 3:

or example: 'test#{2}' would become 'test#01' unless it already exists, in which case it'll become 'test#02' as opposed to just replacing the older file.

What should happen if there already is a file named 'test#2' ?
If something like this is wanted it should cover all eventualities and I need to know whether this is a feature or the file name generation or of the job processing.
To clarify:
During File generation: Existence of file XY would be generated upon job creation. So if you run a job multiple times output would be overwritten.
(atm. 'Generate' option adds a '_new' whenever the file name already exists <- this I would remove)
During job processing: During job processing a Hybrid would check the last 'rename' (or if no 'rename' subjob exists the last processing call to check whether the output exists and adjust the call accordingly - this could be a lot of work.)


Regarding 4:
*.chp (Chapter files) and *.xml (Matroska tag files) should both be created inside the temp folder, not the source folder (unless the source is the temp folder.
+ both should get deleted unless Hybrid is told to keep intermediate files (or the processing is aborted or crashed)
Tested both here and for me the *.chp and the *.xml file both get created inside the temp folder and get deleted during normal processing.
-> If this isn't the case for you, share details and I might be able to fix it.

Cu Selur

[Nuihc88]

Regarding 1.:
This request should go to the x265 developers not me.

I requested it here since this information is mostly already available through Hybrid and the files it produces as long as mkvinfo & mediainfo are up to date. It just takes a while to gather it all manually; except for PSNR & SSIM, as i'm still not sure how to find those values after setting their Metrics on at 'x265 > Misc'.

Regarding 2:
Not going to happen. Intermediate files did at one point contain lots of meta data which causes lots of problems on Windows due to lack of UTF-8 support through a bunch of tools and some Windows combinations. To avoid those problems Hybrid now should use generated names based on the job ID and this is the way it will stay.

I don't think i got the purpose and method of this suggestion properly across...
It would only need to rename the intermediate files (for later reference), after the encoding job is done and full file has been generated. It would only need to use metadata for files supported through mkvinfo & mediainfo. Having a standard source format to read should deal with compatibility problems. If a specified field is not found, it should display nothing and it would be run at the point these files are normally deleted. Readout forwarded to Filename could be limited to supported characters and everything else replaced with something readable.

The real benefit from Suggestions 1 & 2 would be that it would be possible to arrange files by PSNR & SSIM in any file explorer as well as keep track of trends in how .265(, etc.) file's bitrates, sizes and other values correlate with set parameters, essentially turning any file browser into a dynamic comparison chart.

What should happen if there already is a file named 'test#2' ?

What i intend here is that it would always choose the next untaken numerical value and if it reaches #99, it'll go to #100, even if zero padding is set to only 2 digits.

If something like this is wanted it should cover all eventualities and I need to know whether this is a feature or the file name generation or of the job processing.

I would describe it as a quick filesystem check and name correction happening about the same time the job is generating tagging info's, before intermediate files get put into a container.

1. Essentially everything starts with checking whether Generated Filename contains '#{number}', if there is no '#' found, everything is skipped and original file is overwritten.
   
2. When matching files are found for the first time this session, they are listed (internally) and to account for the possibility that user has deleted some of those files (or added a '#00' file), filenames are listed alpha-numerically (number check ends when first non numerical character after # is detected).
   
3. The last filename is used as basis for an availability check: 'generated_hypothetical_filename#'+'detected_number+1' is checked.
   
4. If somehow a new file is generated while this is being checked, +1 is tried, until it's succesful.
   
5. On success the 'new filename' +1 is cached for the next availability check and that check starts at step 3.
   

*.chp (Chapter files) and *.xml (Matroska tag files) should both be created inside the temp folder, not the source folder (unless the source is the temp folder .
+ both should get deleted unless Hybrid is told to keep intermediate files (or the processing is aborted or crashed)

I chose to keep the intermediate (.265 & .aac) files as a workaround, since Hybrid overwrites the .mkv test files i'm generating (as '_new' seems to only kick in occasionally, perhaps due to some condition i'm unaware of; most of my test files only differ by one parameter). I then check their metadata with MediaTab (which internally uses mediainfo).

Tested both here and for me the *.chp and the *.xml file both get created inside the temp folder and get deleted during normal processing.
-> If this isn't the case for you, share details and I might be able to fix it.

This is because i used 'enc\' filename prefix as a workaround in order to get a dynamic subfolder under the source folder. All other temp files get directed to 'enc\' where i want them. I realize i could just set static output and temp paths, but i want to keep my encodes close to my source files. This way i don't get my intermediates from different sources mixed up, nor do i have to jump between tabs as much.

So the point of suggestion 4 is about having full support for dynamic directories for all generated files.

[Selur]

I requested it here since this information is mostly already available through Hybrid and the files it produces as long as mkvinfo & mediainfo are up to date. It just takes a while to gather it all manually; except for PSNR & SSIM, as i'm still not sure how to find those values after setting their Metrics on at 'x265 > Misc'.

Tell Hybrid to create report files ('Config->Internals->Create report file') and you will see something like this:

x264 (1st pass bitrate) processing started...
starting 17_39_52_0610_01_video@17:39:57.702 - H:\Output\Test-AC3-5.1.mp4
"G:\Hybrid\x264.exe" --preset superfast --pass 1 --bitrate 1500 --profile high --level 4.1 --direct auto --sync-lookahead 27 --qcomp 0.5 --aq-mode 0 --sar 1:1 --psnr --ssim --non-deterministic --range tv --stats "H:\Temp\Test-AC3-5.1_17_39_52_0610_01.stats" --demuxer raw --input-depth 8 --input-res 640x480 --input-csp i420 --fps 25 --output NUL -
raw [info]: 640x480p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:4     Avg QP: 5.25  size: 18380  PSNR Mean Y:68.74 U:68.97 V:68.39 Avg:68.54 Global:53.65
x264 [info]: frame P:210   Avg QP: 0.24  size:  1134  PSNR Mean Y:73.67 U:72.37 V:72.11 Avg:73.09 Global:69.33
x264 [info]: frame B:621   Avg QP: 1.96  size:    86  PSNR Mean Y:73.78 U:72.42 V:72.15 Avg:73.17 Global:70.01
x264 [info]: consecutive B-frames:  0.8%  0.0%  0.0% 99.2%
x264 [info]: mb I  I16..4: 89.1%  0.0% 10.9%
x264 [info]: mb P  I16..4:  0.5%  0.0%  0.0%  P16..4:  2.5%  0.0%  0.0%  0.0%  0.0%    skip:97.0%
x264 [info]: mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  0.3%  0.0%  0.0%  direct: 0.7%  skip:99.0%  L0:20.5% L1:79.5% BI: 0.0%
x264 [info]: final ratefactor: -14.21
x264 [info]: direct mvs  spatial:98.4% temporal:1.6%
x264 [info]: coded y,uvDC,uvAC intra: 8.7% 13.7% 11.8% inter: 0.4% 0.4% 0.4%
x264 [info]: i16 v,h,dc,p: 85% 13%  2%  0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 39% 23% 20%  3%  3%  4%  3%  2%  3%
x264 [info]: i8c dc,h,v,p: 69% 17% 13%  0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: SSIM Mean Y:0.9999810 (47.223db)
x264 [info]: PSNR Mean Y:73.727 U:72.391 V:72.120 Avg:73.127 Global:69.056 kb/s:87.37
encoded 835 frames, 1081.61 fps, 87.37 kb/s
finished after 00:00:01.217
finished...

x264 (2nd pass bitrate) processing started...
starting 17_39_52_0610_02_video@17:39:58.926 - H:\Output\Test-AC3-5.1.mp4
"G:\Hybrid\x264.exe" --pass 2 --bitrate 1500 --profile high --level 4.1 --direct auto --sync-lookahead 27 --qcomp 0.5 --no-mbtree --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 62500 --vbv-bufsize 78125 --sar 1:1 --psnr --ssim --non-deterministic --range tv --colormatrix bt470bg --stats "H:\Temp\Test-AC3-5.1_17_39_52_0610_01.stats" --demuxer raw --input-depth 8 --input-res 640x480 --input-csp i420 --fps 25 --output "H:\Temp\17_39_52_0610_02.264" -
raw [info]: 640x480p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [warning]: target: 1500.00 kbit/s, expected: 125.46 kbit/s, avg QP: 0.0000
x264 [warning]: try reducing target bitrate
x264 [info]: profile High, level 4.1
x264 [info]: frame I:4     Avg QP: 0.00  size: 22342  PSNR Mean Y:76.13 U:74.39 V:73.57 Avg:75.24 Global:75.17
x264 [info]: frame P:210   Avg QP: 0.00  size:   785  PSNR Mean Y:76.04 U:74.58 V:74.03 Avg:75.32 Global:75.22
x264 [info]: frame B:621   Avg QP: 1.73  size:    43  PSNR Mean Y:76.10 U:74.61 V:74.04 Avg:75.37 Global:75.27
x264 [info]: consecutive B-frames:  0.8%  0.0%  0.0% 99.2%
x264 [info]: mb I  I16..4: 88.7%  0.1% 11.1%
x264 [info]: mb P  I16..4:  0.3%  0.0%  0.2%  P16..4:  1.0%  0.0%  0.1%  0.0%  0.0%    skip:98.5%
x264 [info]: mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  0.2%  0.0%  0.0%  direct: 0.1%  skip:99.6%  L0:27.8% L1:72.1% BI: 0.1%
x264 [info]: 8x8 transform intra:0.1% inter:22.9%
x264 [info]: direct mvs  spatial:99.5% temporal:0.5%
x264 [info]: coded y,uvDC,uvAC intra: 10.0% 13.6% 11.5% inter: 0.1% 0.1% 0.1%
x264 [info]: i16 v,h,dc,p: 86% 12%  2%  0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 61% 11% 29%  0%  0%  0%  0%  0%  0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 24% 21%  3%  3%  4%  3%  3%  3%
x264 [info]: i8c dc,h,v,p: 72% 16% 12%  1%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 87.1% 11.5%  1.4%
x264 [info]: ref B L0: 97.3%  2.7%
x264 [info]: ref B L1: 99.2%  0.8%
x264 [info]: SSIM Mean Y:0.9999934 (51.833db)
x264 [info]: PSNR Mean Y:76.085 U:74.601 V:74.039 Avg:75.356 Global:75.258 kb/s:67.26
encoded 835 frames, 907.61 fps, 67.26 kb/s
finished after 00:00:01.065
finished...

created H:\Temp\17_39_52_0610_02.264 (0.267804 MB)
starting cleanUpJob for: H:\Temp\Test-AC3-5.1_17_39_52_0610_01.stats
delete H:\Temp\Test-AC3-5.1_17_39_52_0610_01.stats
starting 17_39_52_0610_04_muxing@17:40:00.002 - H:\Output\Test-AC3-5.1.mp4
"G:\Hybrid\MP4Box.exe" -par 1=1:1 -add "H:\Temp\17_39_~1.264"#video:fps=25:xps_inband -brand avc1 -itags tool="Hybrid 2017.11.13.1" -tmp "H:\Temp" -new "H:\Output\17_39_52_0610__04.mp4"
finished after 00:00:00.118
finished...

created H:\Output\17_39_52_0610__04.mp4 (0.278579 MB)
starting cleanUpJob for: H:\Temp\17_39_52_0610_02.264
delete H:\Temp\17_39_52_0610_02.264
renamed H:\Output\17_39_52_0610__04.mp4 to H:\Output\Test-AC3-5.1.mp4

Inside the report file. In older versions the normal log showed these, but that was removed since it caused users to always post their normal 'log'.

Problem with generic tags is most applications don't support them.
Most containers like mp4 and mkv, support a few official tags. (For mkv see https://matroska.org/technical/specs/tagging/index.html.)
And libraries like MediaInfo only support these (not sure if MediaInfo really supports all official mkv tags).
-> So in your case it won't help at all if I would add additional mkv tags since MediaInfo won't detect them and report them.

This is because i used 'enc\' filename prefix as a workaround in order to get a dynamic subfolder under the source folder.

Okay, this feature isn't used as intended and I do not plan to write any workaround for that.

So the point of suggestion 4 is about having full support for dynamic directories for all generated files.

So a different file directory for each type of generated file. -> Sorry, that's not happening.

I chose to keep the intermediate (.265 & .aac) files as a workaround, since Hybrid overwrites the .mkv test files i'm generating (as '_new' seems to only kick in occasionally, perhaps due to some condition i'm unaware of; most of my test files only differ by one parameter).

The '_new' will only checked and added when 'Generate' gets triggered.
For example:
You load a file (or multiple files) into Hybrid and 'Generate' is enabled, Hybrid will check for each file whether a name with it's name exists and will add '_new' in case it does. So assuming you now add a job for the file(s) you added, change your encoding settings and create another job:
a. generate won't get triggered
b. no additional '_new' would get added, even if 'Generate' was triggered since the output file doesn't exist.
c. if you do stuff like changing the output folder through file name generation like you did, Hybrid will look inside the wrong folder.

I then check their metadata with MediaTab (which internally uses mediainfo).

Did some reading up and tested a few things, seems like MediaInfo nowadays supports custom tagging (it even shows non standard tags).
I theoretically could write an option which would add separate tags for any wanted data.
To add PSNR and SSIM results the output of the encoder would need to be parsed and then custom tags would need to be added. (Different code for each multiplexer.)
-> will think about it in case some other users also see a usefulness in this option.

Cu Selur

[Nuihc88]

Tell Hybrid to create report files ('Config->Internals->Create report file') and you will see something like this:

Thanks, this is something i've been looking for, for a while now.

-> So in your case it won't help at all if I would add additional mkv tags since MediaInfo won't detect them and report them. Smile

I haven't actually asked for more tags as such though, but for copying of metadata to output filename. e.g. 'output_filename_bitrate=12345Kbps_size=987654bytes' or 'output_filename_crf=24;qcomp=0.8;pbratio=1.2.mkv'. The exact syntax wouldn't matter either, if ';' or '=' were to cause problems, underscore would do too.

Okay, this feature isn't used as intended and I do not plan to write any workaround for that.

Understandable, but besides the point. I only use it because it's currently closer to what i want than the official implementation for setting directories.

So a different file directory for each type of generated file. -> Sorry, that's not happening.

If i understand you correctly, nope. What i mean is that all intermediate files get put into the same subfolder, that's location is dynamic in relation to either the source or output directory. There is no need to separate each filetype.
Implementations i would find practical would look something like: 'source_folder/encodes/*' with or without the output file, 'output_folder/intermediaries/*' with or without the output file or a new folder named after the output filename (without an extension) such as 'source_folder/output_filename/*' or 'output_folder/output_filename/*'.

The '_new' will only checked and added when 'Generate' gets triggered.
For example:
You load a file (or multiple files) into Hybrid and 'Generate' is enabled, Hybrid will check for each file whether a name with it's name exists and will add '_new' in case it does. So assuming you now add a job for the file(s) you added, change your encoding settings and create another job:
a. generate won't get triggered
b. no additional '_new' would get added, even if 'Generate' was triggered since the output file doesn't exist.

This is consistent with my observations. The way this check works is probably good enough for casual encoding jobs, but when testing and comparing various encoding settings it becomes very inpractical, hence the need to keep the intermediaries, put them in a separate folder, group by type & arrange folder by date. The extra .chp & .xml files in source folder are a rather minor griavance by comparison.

c. if you do stuff like changing the output folder through file name generation like you did, Hybrid will look inside the wrong folder.

Due to points a. and b., knowing this doesn't really make a difference though, hence Suggestion 4.

[Selur]

Btw. if overwriting is a real problem enable 'noOverwriting' through the misc.ini.
see: [INFO] *hidden* Hybrid options,...
This way Hybrid should never overwrite an output file.

Cu Selur

[Selur]

Intermediate files go to the temp folder, unless you tell Hybrid that the temp folder should be the same as the output folder by either selecting:
'Config->Output->Container Settings->Genarl Settings->Keep intermediate files'
or setting:
'Config->Path->Adjust->Temp path to output path'.

Adding another folder which would be used instead of the temp folder seems wrong. That is what the temp folder is for.
-> Adding an option which allows to name a folder that should be used as temp relative to the output folder might solve the problem, but in case the relatively specified temp folder wouldn't exist Hybrid would abort the job creation.

-----------------

About adding data to the output name, it's the same problem as using tags.

• The data has to come from somewhere, meaning the output would have to be parsed and then the tags or the last rename call would need to be adjusted accordingly.
  
• Writing the parser is a pain since:
  • once the encoder changes the output just a little the option would be broken
    
  • each encoder would need a separate parser (since the outputs differ and not all encoders output all values);
    

[Nuihc88]

Btw. if overwriting is a real problem enable 'noOverwriting' through the misc.ini.
see: [INFO] *hidden* Hybrid options,...
This way Hybrid should never overwrite an output file.

Ok, ran some tests and this is somewhat better in that regard, but on the downside it results in very long filenames quite quickly. I'll leave this enabled for now, though.

Adding another folder which would be used instead of the temp folder seems wrong. That is what the temp folder is for.

It would only need to be created when 'Keep intermediate files' is set.

-> Adding an option which allows to name a folder that should be used as temp relative to the output folder might solve the problem, but in case the relatively specified temp folder wouldn't exist Hybrid would abort the job creation.

This would in itself be acceptable for this type of usage scenario, automatically checking for and creating that folder on fly would be even better.
There are however other usage scenarios where setting dynamic paths would also be useful. For example if user were to run Hybrid in portable mode from an USB-stick (as i do) and then move it to another computer... Without dynamic paths you'll need to set these paths manually each time and remember to make sure each directory you set has enough free space available, rather than just checking the free space on the source file's drive.

About adding data to the output name, it's the same problem as using tags.

   The data has to come from somewhere, meaning the output would have to be parsed and then the tags or the last rename call would need to be adjusted accordingly.
   Writing the parser is a pain since:
       once the encoder changes the output just a little the option would be broken
       each encoder would need a separate parser (since the outputs differ and not all encoders output all values);

I guess this will be more of a problem for PSNR & SSIM readouts? In my experience MediaInfo at least seems fairly consistent in it's readouts.
Either way, personally i'd probably implement this using regular expression text searches, like this:
Cache MediaInfo output and search for metadata text readout matching: '[linebreak]File size: ' & copy contents from there on until next [linebreak] is found and remove any spaces. If no matches are found output nothing, if multiple matches are found output longest string by default, if multiple same length strings are found use the first one by default. This way you wouldn't need to separately add support for each possible tag.
It might also be useful to allow user to select one of the other matches and specify a limiter for string length. You could thereby let users specify custom searches using some RegEx like syntax such as:'filename_size=[File size: ]_rate=[{2}Bit rate: (3)]'
With '{2}' being one possible implementation for selecting the second match and '(3)' being one possible implementation of a custom limiter for cutting off excess text where necessary.
Example output in this case would be something like: 'filename_size=12345bytes_rate=123'+.extension
Since this would be a feature for advanced users, when something breaks, normally they'd be able to find out why and correct it for themselves.

PS. Adding PSNR & SSIM to custom tags and/or filename would certainly be a nice feature, but even MediaInfo readouts can be very useful by themselves.
Copying recent changes to 'Encoding settings:' over to filename could be somewhat tricky as well, but probably also the most useful.

Personally i would solve the Encoding settings parsing problem with something like this:

1. On MediaInfo readout, RegEx Replace with nothing: '[linebreak]Encoding settings :' & copy rest of the line.
   
2. Add extra [linebreak] at the very end & Replace every '/' with '[linebreak]' to use as separator for searching subsequent matches.
   
3. RegEx Search for matches from user input using '[space]' as starting and ending character +'[linebreak]', in order to avoid false matches from parameters starting with 'no-' and ending with a multi-digit number.
   
4. When it matches user input RegEx Replace it with nothing.
   
5. RegEx Replace remaining '[linebreak]' characters with ';' and remove the last one.
   
6. RegEx replace every '[space]' with nothing.
   
7. Append the target filename with whatever is left.

[Selur]

It would only need to be created when 'Keep intermediate files' is set.

Argh. I would prefer to not create folders in Hybrid if at all possible.

-----------------------------------------------------------------------------------------------

Personally i would solve the Encoding settings parsing problem with something like this:

1. On MediaInfo readout, RegEx Replace with nothing: '[linebreak]Encoding settings :' & copy rest of the line.
   
2. Add extra [linebreak] at the very end & Replace every '/' with '[linebreak]' to use as separator for searching subsequent matches.
   
3. RegEx Search for matches from user input using '[space]' as starting and ending character +'[linebreak]', in order to avoid false matches from parameters starting with 'no-' and ending with a multi-digit number.
   
4. When it matches user input RegEx Replace it with nothing.
   
5. RegEx Replace remaining '[linebreak]' characters with ';' and remove the last one.
   
6. RegEx replace every '[space]' with nothing.
   
7. Append the target filename with whatever is left.
   

This sounds more like something that should be done in a separate tool.
Like a small program (or script) which you feed with a file and a bunch of parameter.

Something like:

MediaInfoRenamer --Inform=<InformCall>  --Separator=<used seperator> --Merger=<append> <File>

Options:

• --Inform: 'Inform'-parameters for MediaInfo. Call "MediaInfo --Info-parameters" to get a full list of supported options.
  
• --Separator: The separator used inside the 'Inform'-parameter.
  
• --Merger: The text that should be used to combine the collected data.
  
• File:: The file which should be analyzed and renamed.
  

For better understanding of what I mean with this.
Here a few examples:

Example 1:

MediaInfoRenamer  --Inform="Video;%Width%,%Height%,%BitRate%,%FrameRate%" --Separator=","--Merger=" " "z:\Output\myfile.mkv"

The tool then would:
a. call:

mediainfo --Inform="Video;%Width%,%Height%,%BitRate%,%FrameRate%" "z:\Output\myfile.mkv"

and collect the output.

640,352,722134,25.000

b. split the output using the separator:

• 640
  
• 352
  
• 722134
  
• 25.000
  

c. join that data using the merger:

640 352 722134 25.000

d. rename the file from:

"z:\Output\myfile.mkv"

to

"z:\Output\myfile 640 352 722134 25.000.mkv"

Example 2:

MediaInfoRenamer  --Inform="Video;%Width/String%#%Height/String%#%BitRate/String%#%FrameRate/String%" --Separator="#" --Merger="_" "z:\Output\myfile.mkv"

The tool then would:

a. call:

mediainfo --Inform="Video;%Width/String%#%Height/String%#%BitRate/String%#%FrameRate/String%" "z:\Output\myfile.mkv"

and collect the output.

640 pixels#352 pixels#722 kb/s#25.000 FPS

b. split the output using the separator:

• 640 pixels
  
• 352 pixels
  
• 722 kb/s
  
• 25.000 FPS
  

c. join that data using the merger:

640 pixels_352 pixels_722 kb/s_25.000 FPS

d. try to rename the file from:

"z:\Output\myfile.mkv"

to

"z:\Output\myfile_640 pixels_352 pixels_722 kb/s_25.000 FPS.mkv"

and fail since '/' isn't allowed inside a file name.

Note: The following character are reserved and thus will cause problems:

• : (colon)
  
• " (double quote)
  
• / (forward slash)
  
• \ (backslash)
  
• | (vertical bar or pipe)
  
• ? (question mark)
  
• * (asterisk)
  

Example 3:

MediaInfoRenamer  --Inform="Video;Width %Width/String%#Height %Height/String%#%Bitrate BitRate/String%#Framerate %FrameRate/String%" --Separator="#" --Merger="_" "z:\Output\myfile.mkv"

The tool then would:

a. call:

mediainfo --Inform="Video;%Width/String%#%Height/String%#Bitrate(kBit pro sec) %BitRate%#Framerate(fps) %FrameRate%" "z:\Output\myfile.mkv"

and collect the output.

Width 640 pixels#Height 352 pixels#Bitrate(kBit pro sec) 722#Framerate(fps) 25.000

b. split the output using the separator:

• Width 640 pixels
  
• Height 352 pixels
  
• Bitrate(kBit pro sec) 722
  
• Framerate 25.000 FPS
  

c. join that data using the merger:

Width 640 pixels_Height 352 pixels_Bitrate 722_Framerate(fps) 25.000

d. rename the file from:

"z:\Output\myfile.mkv"

to

"z:\Output\myfile_640 pixels_352 pixels_722_Framerate(fps) 25.000.mkv"

Cu Selur

[Nuihc88]

This sounds more like something that should be done in a separate tool.
Like a small program (or script) which you feed with a file and a bunch of parameter.

Something like:

Quote:
MediaInfoRenamer --Inform=<InformCall> --Separator=<used seperator> --Merger=<append> <File>
Options:

--Inform: 'Inform'-parameters for MediaInfo. Call "MediaInfo --Info-parameters" to get a full list of supported options.
--Separator: The separator used inside the 'Inform'-parameter.
--Merger: The text that should be used to combine the collected data.
File:: The file which should be analyzed and renamed.

Hmm... It would also need a way of being pointed towards user's baseline reference for Encoding settings or it won't be able to shorten the output, as well as towards the correct '*_Report.txt' file for PSNR & SSIM parsing if/when implemented here. Other than that this looks good.