GSpot v2.60 b00

[unskinnyboy]

v2.60 b00 still indicate the number of AC3 channels wrong. It was a problem with the previous builds too. For e.g: a file with 6Ch AC3, GSpot says it is 2Ch. VirtualDubMoD reports the channel info correctly.

One very common and annoying problem with the previous builds was that, on some files, it would report the wrong audio information and then use *that* to calculate the video bitrate, and in the end report wrong video bitrate too. In v2.60 b00, since the video is being demuxed out first, the video bitrate is accurate, so at least that part is OK. Just the audio info is wrong.

[SeeMoreDigital]

v2.60 b00 still indicate the number of AC3 channels wrong. It was a problem with the previous builds too. For e.g: a file with 6Ch AC3, GSpot says it is 2Ch. VirtualDubMoD reports the channel info correctly.In my experience, previous GSpot builds would report 6Ch AC3 streams as having 5 channels!

I've just used VDM to mux an MPEG-4 video stream together with an 6Ch AC3 stream and got this: -

http://img96.imageshack.us/img96/2571/gspot6chac3testku7.png


Cheers

[clsid]

Perhaps it only reports the numbe of channels incorrect in specific situations. If unskinnyboy provides a sample file, then Stegre can try to reproduce and fix the problem.

[unskinnyboy]

In my experience, previous GSpot builds would report 6Ch AC3 streams as having 5 channels!
Note that your screenshot says 5.1 and not 5, and that is correct. 6 Channels is also referred to as 5.1, where the 5 stands for the normal-range speaker outputs (RF, C, LF, RR, LR) and the 0.1 for the LFE. So what you see is correct.

Perhaps it only reports the numbe of channels incorrect in specific situations. If unskinnyboy provides a sample file, then Stegre can try to reproduce and fix the problem.
Yes, it happens only with certain files. I will upload a sample later.

[SeeMoreDigital]

Note that your screenshot says 5.1 and not 5, and that is correct. 6 Channels is also referred to as 5.1, where the 5 stands for the normal-range speaker outputs (RF, C, LF, RR, LR) and the 0.1 for the LFE. So what you see is correct. Yes... I know it's correct!

I am however, unable to replicate what you are seeing. So as clsid suggests, can you provide a sample?


Cheers

[stegre]

Yeah, as unskinny boy says "5.1" is correct and technically more informative than "6" (well, in this particular case, for AC3, "6" would have to mean "5.1", as AC3 only supports 5 "full bandwidth" channels max so a sixth would have to be an LFE (i.e. "Low Frequency Effects" i.e. a "subwoofer" channel). The "5.1" style terminology is not something I made up, btw, it's commonly used by audiophiles and in audio equipment specs.

As you can see in the spec below, "nfchans" ("number of full bandwidth channels") maxes out at 5. For clarity I could change the terminology to say ("6 chnls [5.1.]") or something.

The existence of an extra "LFE" channel can be added to any of the modes below, so there are really 16 different combinations ( at least in theory): any of the eight below with an extra LFE and any of them without one. They treat the LEF channel as a separate entity presumably because it's coded to use less bandwidth than the "full" channels (since there's no need - in fact it's probably undesirable - to encode all the hi-frequency components to send to a subwoofer).

So actually, when I use the "dot" terminology, it's more informative. Note the chart below (where, btw, "S" means "surround" aka "rear": e.g. "SL" is "rear left"). Ignoring the first oddball mode "0", if I said "2" channels it would have to be "L + R". I'd say "2.1" if it were "L, R" plus subwoofer. In the latter case VirtualDubMod, I assume, would say "3", which could mean either L + R (2 full range channels) with one LFE subwoofer channel, or it could also mean either L, R, C or L, R, S (each of those being 3 full range channels).

In fact, even my current terminology doesn't fully specify speaker placement, (my "3" could mean L, R, C or L, R, S) but at least it pares down the combinations in that regard, and in any event always identifies the LFE channel as separate entity, as it is indeed "different" than the other channels.
http://www.headbands.com/gspot/misc_images/ac3.png

[stegre]

...For e.g: a file with 6Ch AC3, GSpot says it is 2Ch. VirtualDubMoD reports the channel info correctly.But back to this original question, yes, if it's reporting 2 channels for a "5.1" / 6 chnl AC3 stream that's clearly in error. I was about to post a GSpot update, beta 01, as early as today -- but let me take a quick look at the AC3 handling first. I'll test it on a bunch of files I have here, but it would be great if you could post your testfile as well in case I can't reproduce it. And I admit, I'm already seeing some weird things in a few very quick tests I did in the last few minutes, so there are indeed probably some bugs in that area.
...it would report the wrong audio information and then use *that* to calculate the video bitrate, and in the end report wrong video bitrate too. In v2.60 b00, since the video is being demuxed out first, the video bitrate is accurate, so at least that part is OK. Just the audio info is wrong.
Yes, what you're describing is exactly what I did in earlier versions: In the absence of better info, I'd often use (when I only had the movie's duration, audio bitrate and overall total filesize):

TotalAudioSize = AudioBitrate * Duration
TotalVideoSize = TotalFileSize - TotalAudioSize;
VideoBitRate = TotalVideoSize / Duration

But I'd like to use that only as a last resort in these newer versions. As you say, one disadvantage of the above is that if there IS an error in the audio calc, it gets propagated to the video. It also introduces errors related to container overhead, and possibly significant errors if the container contains additional unidentified streams (though I do account for the simple case multiple audio streams when I do the above calculation).

As I add more capabilities to GSpot internally, my options increase - in fact to list a few, all of which are preferred over the above (though not necessarily in this order):

1) Display VideoBitRate as specified in a container, if available.
2) Display Video Bitrate as specified in a "header" chunk of a video stream demuxed from the container, if available, and if GSpot "understands" the format it's demuxing.
3) Display VideoBitRate calculated after demuxing the entire video stream, counting the bytes, and dividing by the duration (which doesn't necessarily require "understanding" the format of the demuxed video stream).

I have been improving, as you mentioned, and will continue to attempt to improve on using the best method available for each given situation.

[unskinnyboy]

Houston, we have a problem. On the whole file (which is a full length encode), GSpot reports 48000Hz 384 kb/s total (2 chnls), but on a sample cut out of it, GSpot says 48000Hz 384 kb/s total (5.1 chnls), the latter being the correct info.

Steve, I don't mind uploading the full file to you if it will help troubleshoot this issue. I will follow up with a PM.

[unskinnyboy]

Steve, what exactly in the avi are you looking at when you report 'garbage at end'? And why only for OpenDML avis > 2 GB? Would like to hear you out on this. Thanks.

FYI - http://forum.doom9.org/showthread.php?t=116852

[stegre]

I'll get back to that question and some other stuff about various updates I've made, especially ones related posts in this thread, but I just wanted to quickly mention that I've just posted an update: so here's quick links to the GSpot v2.60 b01 download page (http://www.headbands.com/gspot/v26x/index.html) and the associated list of changes page (http://www.headbands.com/gspot/v26x/b01_updates.html). BTW, regarding representation of AC3 channels (earlier in this thread) I did my "doom9 homework" and found this sticky thread (http://forum.doom9.org/showthread.php?p=332259#post332259) under Doom9's Forum > General > Audio encoding, where the fifth section down, "Basic Parameters", specifically discusses the proper "official" way to represent the number of full range channels, LFE channel, and speaker layout as well - a representation basically backed up the referenced specification document there. So I've adapted the terminology described there in this new version, as mentioned in my update notes (along with a small screenshot).

Anyway, I'll be back - I need a brief rest now ;)

[clsid]

Great update. Here are my test results and comments:

* Codec & Filter list: 'Set filter merit' should be disabled when you right-click on an ACM or VFW codec.

* I have VMware installed. GSpot will list the file "vmnc.dll" as missing. However the file is present and working correctly. I think something goes wrong when GSpot tries to instanciate the codec (or whatever it does to gather additional info). Let me know if I need to upload the file for you.

* GSpot does not yet recognize the file type of .amr files.

* Missing FourCC: l263 (small L) = Leadtools h264

* FLV file shows compatibility warning "Requires Flash 6+ capable player". Gabest's FLV splitter (SVN rev611 build) is capable of playing FLV files. Both splitting and decoding the FLV1/FLV4 video. So there isn't really a requirement for a special player.

* QuickTime v7 MOV files (containing H.264/AAC) are very similar to regular mp4 files. Perhaps you can add parsing of that specific type of MOV files when you add MP4 parsing.

* I have got a few Matroska files that contain a lot of different audio streams. Opening such a file in GSpot will freeze the system for short while (half a minute or so). After that GSpot will still be unresponsive (with 0% cpu usage), but I regain system control. Sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv).

* GSpot does not yet recognize the file type of .nsv (Nullsoft video).

[SeeMoreDigital]

Hi Steve,

Great work with the new build...

Nice to see you've included the "MetaData" build information for MPEG-4 streams... Very useful :)

Many thanks for making the VOP information easier to understand too!

I like it mate :D


Cheers

[unskinnyboy]

Houston, we have a problem. On the whole file (which is a full length encode), GSpot reports 48000Hz 384 kb/s total (2 chnls), but on a sample cut out of it, GSpot says 48000Hz 384 kb/s total (5.1 chnls), the latter being the correct info.

Steve, I don't mind uploading the full file to you if it will help troubleshoot this issue. I will follow up with a PM.

This is fixed with the new build. GSpot v2.60 b01 detects the AC3 stream on my file correctly as 48000Hz 384 kb/s total , 6 chnls (3/2 .1) now. :thanks:

[stegre]

GSpot v2.60 b02 (http://www.headbands.com/gspot/) is available now, with a bunch of fixes (including some stuff I "broke" on the previous version;) and other updates I'll mention here and in more detail on the web page shortly.

BTW, The AC3 still wasn't completely right on even on b01; I found it often erroneously indicated ".1" (LFE) channel even when it wasn't present. I think it should finally be accurate now.

[Jekill]

Hi Steve, I have to make you a question about two files I've been testing with your latest versions.

The test files I'm dealing with are taken from DivXTest CD of DivXTest.com.
Here are the links to the single downloads:

Multi B-Frame no packed bitstream (http://www.webalice.it/m.dibacco/multi_B-Frame_no_packed_bitstream.avi)
Multi B-Frame with packed bitstream (http://www.webalice.it/m.dibacco/multi_B-Frame_with_packed_bitstream.avi)

In particular, I encountered problems with the recognition of Packed Bitstream.
Reading the "posts" and "links" of this thread, I learned that NVOP should be the clue of Packed Bitstream.

The question is why with GSpot 252 b01.rar and GSpot 260 b00 NVOP is retrieved for both files while, using GSpot 260 b01 and GSpot 260 b02, it isn't detected for no one of them.

Am I wrong or there should be a problem with the files themselves?

The fact is that the two latest betas doesn't detect PB also for another file I created, for which, on the contrary, it was retrieved by the former versions.

Hope I've been useful.
Bye.

[SeeMoreDigital]

Hi Jekill,

Those particular, 1B-VOP, 2B-VOP and 3B-VOP clips were encoded separately and joined together into one continuous stream afterwards. The same was done with their GMC sample!

Meaning, neither are representitive of what you'll be able to encode yourself!

I recommend you forget about them and not consider using them!


Cheers

[Jekill]

Ok, thanks a lot, SeeMoreDigital.
I didn't consider that.

Bye.

[stegre]

Actually, thanks, those files are interesting, regardless of how they were created. I haven't seen those before, and I'm going to take a closer look to decide if I'm reporting everything the way I think I should. It does seem that the NVOP "light" should be on, and I also had, in previous versions, a "Packed Bitstream" message in the container information area. It does seem like those should be present for the one file.

But yes, SMD, is correct in that they are "weird", as they were apparently created by setting the encoder to a certain setting (e.g. "1 B-Frame max"), encoding a segment, then changing the encoder parameters and encoding a different segment, etc, and then appending all the segments together. But there's nothing really "illegal" about doing that or the files themselves (not that I see so far, anyway) so I'm going to convince myself that I'm reporting it all correctly. For example, for a while the files say (and do) have "1 consec B-Frame", then they "2" for a while, and finally "3". And I do report "3 max consecutive B-Frames", which certainly would be the correct value for the file overall.

In fact if you press the "VGS" button on GSpot on those files, it visually shows an areas with one, then two, and then later three consecutive B-Frames (the green rectangles are the B-frames). And it shows occasional vertical blue bars which are "packed bitstream markers" on the file that's supposed to have them (see screenshot below), and not on the other file. So that much seems correct. But I'm not quite sure what's going on in the very beginning of these files, nor am I sure why I'm not displaying NVOP and/or "Packed Bitstream" message in the main dialog for the one file, as you've asked. Whatever's going on in the beginning may be confusing it, oir maybe I've just broken something. So thanks, I'll check into that.

http://www.headbands.com/gspot/v26x/avi_d_frame/images/multi_B-Frame_with_packed_bitstream.avi.vgs.png

PS I've been very busy which is why I haven't even updated my web site as to what's new in the latest version, nor responded to a lot of the previous questions here. Nor have I spent much time checking the app itself much yet ;) But I will do all that, soon as I can.

[Jekill]

Ok, thanks for the regard.

So, as you explained in first notes of 2.60 version, it's possible to detect PB from vertical blue bars in VGS.
It's a good way and it does work well.
Hope you'll succed in solving NVOP "light" displaying problems.

Glad to be useful.

Bye.

[bobbel]

Thanks a lot for the update.
It's an amazing app and it makes fun to play with :)

Have a nice weekend!

[unskinnyboy]

http://img301.imageshack.us/img301/2576/gspotbugwc0.png

"Copy All Lines to Clipboard as Text" doesn't work. I would expect it to copy all the entries under a section, but it copies only the last entry, whichever line I highlight. Under "Container", it copies only the AVI Overheard information and under "Userdata / Metadata", it keeps copying only the [USER] userdata string. Clearly a bug.

Build is v2.60 pß02.

[numaios]

Thank you very much for this new version!

I've been using GSpot since a long time ago and it is essential to me. And even more now that I can see how many consecutive B-frames there are.

Added: I've analyzed an MP4 file encoded with Nero Recode 2 in AVC profile, with HE-AAC 5.1 audio, and it's reported as "MPEG-4 AAC LC" and "24000Hz 160 kb/s tot (6 chnls)". Maybe it's a problem with the metadata created by Nero Recode?

[clsid]

I have some suggestions for the tests at the bottom of GSpot:

I think the label "MS A/V" is a bit unclear. Perhaps you could rename it to "Render test".

It would be useful if the render log would display the details of the filters used in the DS graph (below the current info). I know I can hover over the filters to see their filenames. But I think it would be easier if the information was displayed more directly. For example just an enumeration of all filters in the graph with the following info: name, path + filename, clsid and file version. Similar to what the CCCP insurgent tool does.

A 'copy to clipboard' context-menu item would be a handy addition. So that people can post their render logs at forums, etc.

[stegre]

OK, I'll get back to the above comments/suggestions/bug reports shortly, but:

...The question is why with GSpot 252 b01.rar and GSpot 260 b00 NVOP is retrieved for both files while, using GSpot 260 b01 and GSpot 260 b02, it isn't detected for no one of them....

Jekill is correct that the last version (or two?) had messed up NVOP / "packed bitsream" detection - there's now a b03 version (http://www.headbands.com/gspot/v26x/) which not only fixes but also enhances that whole area (screenshot below). I'll explain more later.

http://www.headbands.com/gspot/v26x/images/pb.gif

[Jekill]

Hey, first I have to express my gratitude for the shown attention.

Great work.
I've tested your last release and found it really accurate, both in detecting "PB" presence and in distinguishing different packaging methods and frame kinds.

I found it very instructive and I'm sure it'll spread further knowledge, among people, about digital videos several characteristics.

Hi and good job... :)

[unskinnyboy]

On a Multipart OpenDML AVI 2+ GB, v2.60 pß03 reports wrong length, and hence wrong bitrate, Qf, everything. On the muxed file, where the real length was 02:06:18, GSpot said 1:52:59. I demuxed the video out and things got a bit better - GSpot now said the length was 02:04:15. Close, but no cigar.

In both cases, under the 'Container' info, GSpot says there are a few bytes unneeded junk at end of file. I don't remember seeing that with other 2+ GB files before. I don't have other 2+ GB files available immediately for testing that though. Not sure how I can help you troubleshoot this one, but if needed I can upload the full file to you. Or if you need more info, just ask.

[stegre]

OK there's a version b04 (http://www.headbands.com/gspot/v26x/index.html)already, addresses various things in this thread & others, I'll be back to discuss all the prev stuff, and meanwhile anyone please feel free to post comments on old or new stuff. Can't work or even post much myself for the next few days though, gotta get a bunch of stuff finalized in the next few days for next week's "trade show" related to my day job.

[JarrettH]

thanks for updating. i'll switch back now!

[numaios]

Thanks for the new version :)

Is it possible to fix the AAC profile identification? It reports LC when it's actually HE.

[unskinnyboy]

OK there's a version b04 (http://www.headbands.com/gspot/v26x/index.html)already, addresses various things in this thread & others, I'll be back to discuss all the prev stuff, and meanwhile anyone please feel free to post comments on old or new stuff. Can't work or even post much myself for the next few days though, gotta get a bunch of stuff finalized in the next few days for next week's "trade show" related to my day job.The issue I reported about the incorrect length in my previous post is gone with ß04. Another thing bugging me though. The video is not being demuxed out for certain files (including the file with which I had the length issue), but for certain others, they are. :confused: The bitrate on the ones not being demuxed/scanned and right away reported are a bit off. Are you caching the values for files previously checked or something?

[stegre]

The issue I reported about the incorrect length in my previous post is gone with ß04. Another thing bugging me though. The video is not being demuxed out for certain files (including the file with which I had the length issue), but for certain others, they are. :confused: The bitrate on the ones not being demuxed/scanned and right away reported are a bit off. Are you caching the values for files previously checked or something?

I think what's happening is this: Right now, the "main" portion of the GSpot code has no problems with "multi-part" AVI files, but the newer ("demux & scan") related features only scan the first part. This is a temporary limitation; I'll probably have it fixed in the next version. Normally, it wouldn't be much of a problem, as AVI files don't even need a second part until they reach 2GB (though some people say 1GB) in length. When they originally envisioned AVI's, they never thought they'd get that big so didn't really properly allow for it. The "multi-part" format standard was created to combat the limitation. But even now, most files are shorter than 2GB, and even if they aren't GSpot should be able to get a pretty good representation for estimation from scanning the first one or two gigs.

But "Alex", as I think his name is, author of AVIMuxGui, decided a few years ago to depart with tradition (and probably the "spirit, though not the letter" of the AVI format's specification) - and he did it for a rather unusual reason. He changed the defaults of his app to make a VERY short first part (like 1 or 10MB - less than 1% of what would be "normal"), and then followed that by additional "full" length parts. He apparently did this to "fake out" Windows XP explorer, to circumvent some Windows bug. I think his goal of changing the traditional format all the AVI's in the world to fix a Windows XP bug is rather like the cart pulling the horse, though I suppose it's more effective than "asking Microsoft to fix it ;)

Anyway, off that subject, here's good news: 1) I'm gonna update GSpot to scan all the parts of all multi-part AVI's, regardless of why and how they were made, and, 2) meanwhile, while you're waiting, you can confirm my hypothesis: the two latest GSpot versions now report how many parts there are in any "multi-part" AVI, as well as how may frames are in the first part and how many in the others. So if you're curious, you can confirm that the files you have that aren't getting the "full scan" have a relatively small number of frames in the first part (in which case no doubt you'll also see an "AVIMuxGui" tag in the metadata section!).

Anyway, in other news, believe it or not I just had to release another beta version, beta 05 (http://www.headbands.com/gspot/v26x/index.html), after only two days -- because I inadvertently put in two lines of code that made the beta 4 version "non-Win9x-compliant". And starting getting a bunch of hate mail ;) But there's a couple of other fixes in there too, including much better recognition of which exact version of XviD or DivX encoded a given file, for those who are interested in that kind of thing.

[foxyshadis]

Ah, so that's why some people I know dislike Avimuxgui so much.

[SeeMoreDigital]

But "Alex", as I think his name is, author of AVIMuxGui, decided a few years ago to depart with tradition (and probably the "spirit, though not the letter" of the AVI format's specification) - and he did it for a rather unusual reason. He changed the defaults of his app to make a VERY short first part (like 1 or 10MB - less than 1% of what would be "normal"), and then followed that by additional "full" length parts. He apparently did this to "fake out" Windows XP explorer, to circumvent some Windows bug. I think his goal of changing the traditional format all the AVI's in the world to fix a Windows XP bug is rather like the cart pulling the horse, though I suppose it's more effective than "asking Microsoft to fix it ;) There's some information about this on Alexander Noé's web site: http://www.alexander-noe.com/video/amg/en_faq.php


Cheers

[unskinnyboy]

meanwhile, while you're waiting, you can confirm my hypothesis: the two latest GSpot versions now report how many parts there are in any "multi-part" AVI, as well as how may frames are in the first part and how many in the others. So if you're curious, you can confirm that the files you have that aren't getting the "full scan" have a relatively small number of frames in the first part (in which case no doubt you'll also see an "AVIMuxGui" tag in the metadata section!).OK, for avis muxed with AVI-Mux GUI, what you said holds true and I understood your theory too. But, your hypothesis is not true, because for my Multipart OpenDML AVI 2+ GB with 2 parts where the first part is 162515 frames and the second is 19178 frames, the file is _not_ being scanned and it was _not_ muxed by AVI-Mux GUI either (it was muxed by VirtualDubMoD 1.5.4.1 b2178).

Regardless of the number of parts there are, or the size of each part, I would suggest that you should demux the entire video and then compute the bitrate and other values. I don't think any amount of guesstimation should be done here. Accuracy is more important here, not the time elapsed.

As for alexnoe, I am OK with what he has been trying to do. He has always been careful never to break the specs, although I do admit that he lives on the edge. If something is not explicitly disallowed in the specs, you can be sure that he'd take a whack at it.

Ah, so that's why some people I know dislike Avimuxgui so much. This is OT for this thread, but alexnoe does provide standalone specific profiles which would allow AVI-Mux GUI to write out the AVIs à la VirtualDubMoD. They should be using that instead of disliking the tool.

[stegre]

Ah, so that's why some people I know dislike Avimuxgui so much.
...or maybe it has something to do with this dialog I got using it the other day

http://headbands.com/gspot/misc/stupid_user.png

:eek:

But his app does produce good output, has override options, and this is indeed OT....But, your hypothesis is not true, because for my Multipart OpenDML AVI 2+ GB with 2 parts where the first part is 162515 frames and the second is 19178 frames, the file is _not_ being scanned and it was _not_ muxed by AVI-Mux GUI either (it was muxed by VirtualDubMoD 1.5.4.1 b2178).You're absolutely right, I mis-stated my "temporary resolution" above, I just looked and what I did was coded to "not scan at all any AVI that has more than one part"
Regardless of the number of parts there are, or the size of each part, I would suggest that you should demux the entire video and then compute the bitrate and other values. I don't think any amount of guesstimation should be done here. Accuracy is more important here, not the time elapsed.I totally agree, and that's exactly what I'm going to do.

[GrofLuigi]

Please display the total playing time of the clip at all times, if possibly with big shiny numbers. :)

For me, it is the most important feature of the clip, and I often have to wait for the bitrate scan to finish (which, as we know, can take quite some time - and I don't want to give up on that too). Maybe a separate box if not too hard to implement?

Also, display the total playing time for audio files? I've tried with .wav and .ac3 and GSpot doesn't show it.

Apart from that, it's a very nice program indeed.

Thank you!

GL

[stegre]

Meanwhile, I do have an update which I've now designated GSpot v2.60 RC01 (http://headbands.com/gspot/). Since the app is now officially recommended by Microsoft in their main WMP 11 FAQ (http://www.microsoft.com/windows/windowsmedia/player/faq/codec.mspx#q14_5), I figured I'd name it something a little less likely to scare off the newbies, so it's no longer a "beta" ;)

Anyway, on a more interesting level, a new feature is the ability bring up the "third party" property sheets (http://headbands.com/gspot/v26x/prop_sheets.html) for DirectShow filters that support them.

[SeeMoreDigital]

... I figured I'd name it something a little less likely to scare off the newbies, so it's no longer a "beta" ;)So you're hoping the name "GSpot" isn't going to scare them then.... LOL?


Cheers

[G_M_C]

[...] as AVI files don't even need a second part until they reach 2GB (though some people say 1GB) in length. When they originally envisioned AVI's, they never thought they'd get that big so didn't really properly allow for it.
[...]

That why we have OpenDML AVI's ;) They have absolutely no problem with beeing bigger than 2 Gb's. If i understend correctly they max out fat into the terabyte region ;)

PS: I regulary make AVI's @ 4.660.000 Kb length (== DVD size). For instance a 4 part docu, that I encode into 1 very big file and then split up in its seperate parts. Just to make shure I use every bit that I can on parts that need it ;)

[stegre]

FYI, I'm updating the MP4 support and to, among other things, show information extracted from "ftyp" values:

http://www.headbands.com/gspot/misc/ftypes.png

which got me sidetracked trying to collect together that information, and ended up making a small website (http://ftyps.com/) myself since the info didn't appear to be collected anywhere else. Not to crosspost, but I described it in a bit greater detail this thread (http://forum.doom9.org/showthread.php?t=119068) in the MP4 forum.

[red van man]

thanks dude:readrule:

[frogman]

@Stegre btw thank you for a your great tool.
Question when do you expect gspot to read the new vc-1 and dd plus formats in your proggy! This would help me in the demuxing of vc-1 format or identifing .evo containors.
Ps. I am still new to this process and learning as I go.
Thanking you in advance.

[stegre]

I'm just got very "involved" in VC-1 in the last week or two, which is actually what has delayed the release referred to above. I'm about to add VC-1 support now - both for "advanced profile VC-1 elementary streams", or VC-1 in a WMV container. In fact I'll be adding support for anything that's inside a WMV - at least in limited form - previously, it didn't even deal with WMV at all beyond simply identifying it as a WMV file. So this is kind of a double update. It's also going to add limited handling for .mov, especially the newer ones which are almost the same as .MP4. As above, previously it only "identified" .mov. files.

I haven't even looked into .evo yet, so the current plan is to release the update with everything mentioned so far, maybe this week. Then I'll move on to the .evo and stuff, not to mention Matroska, which I'm getting a LOT of requests for.

[clsid]

Great news :)

[HeadBangeR77]

(...)
(...)

He changed the defaults of his app to make a VERY short first part (like 1 or 10MB - less than 1% of what would be "normal"), and then followed that by additional "full" length parts. He apparently did this to "fake out" Windows XP explorer, to circumvent some Windows bug. I think his goal of changing the traditional format all the AVI's in the world to fix a Windows XP bug is rather like the cart pulling the horse, though I suppose it's more effective than "asking Microsoft to fix it ;)
Finally I've G-spotted (:D) this thread.
First of all, many thanks for your application, which I've been using for long years now. :) I was hoping for some update deep in my heart, and suddenly found a new version, downloaded, and found it very functional.

Secondly, to the matter: it's even worse than described above. The so called "legacy index" (sort of a fake container's header, pointing to AVI 1.0) could be disabled now, as well as practicaly any other option concerning AVI 1.0 & AVI Open-DML. The problem is, it doesn't help at all. The header is smaller, true enough, the file stays however multi-part (or multi-segment, I'd rather say). Disabling rec-list and some other things, leaving (at least in theory) "naked" AVI 2.0 as it should be, makes no difference. The resulting file cannot be scanned by your application or any other I've used so far. I think it's not only me who would be very grateful, if you managed to overcome this problem. ;)

Btw. any chances to look deeper into mkv internals with your utility?

regards,
HDBR77

[keys]

I've got a question and I hope it's not a dumbass one. Is it possible to introduce the facility to compare two files and determine which has the better picture quality?

Let me explain what I mean and I hope it becomes clearer.

Let's say I have two copies of the same film - both copies with the same bitrate and roughly the same size. However one film has only been re-encoded only once whereas the other film has been re-encoded twice. To the naked eye on the computer screen there probably won't be that much difference and you'd have real trouble deciding which was the better of the two to keep.

How easy or difficult would it be to introduce some sort of comparisson facility? Or indeed does such a thing already exist elsewhere?

[HeadBangeR77]

How easy or difficult would it be to introduce some sort of comparisson facility? Or indeed does such a thing already exist elsewhere?
You're talking about metrics like PSNR, SSIM etc. G-Spot is an information tool however. If you want to compare e.g. two files with the original, then use MSU Video Quality Measurement Tool - the only downsize I could think of: it's very slow (no optimizations) and runs with high CPU priority thus slowing the other applications incredibly.

Btw. Ctrl+O doesn't work for me with RC-1. Anyone with the same problem?

[LotharZ]

Btw. Ctrl+O doesn't work for me with RC-1. Anyone with the same problem?

Yep, I can confirm that problem.

[joseph5]

Yep, I can confirm that problem.Me too.

[hsoftwaremaster]

I like GSpot. Thank you for developing it, free useful.