Winff should not suppress whole part of filename after dot (.)

[GoogleCodeExporter]

What steps will reproduce the problem?

1. get a few video files named e.g. dv1.mov01 ... dv1.mov02
2. add them to queue in winff
3. convert to (for example) flv format
4. when winff pass parameters to ffmpeg (i think) it suppress whole part of
filename after a dot (.), when it is not necessarily this filename 
extension. in result after converting dv1.mov01 to dv1.flv, it start with
another filename with different name (e.g. dv1.mov02), but save it to file
dv1.flv (same as previous).

What is the expected output? What do you see instead?

I think that winff should not suppress any of the filename's part, instead
just add new extension at the end of new filename.

What version of the product are you using? On what operating system?

winff 1.0.0 
debian sqeeze

Please provide any additional information below.

I use winff for converting videos to flv format for presentation in
internet. It must convert files previously created in Cinelerra. It
frequently happens that Cinelerra render result a few files, that differs
only in number at the end of filename. Converting it in batch with winff
does not produce what user expects :)

It can appear as a minor bug, maybe in Cinelerra, but I think it is
important thing for winff, it can lead to waste time and obscure the way
the program works.

ps. sorry for (maybe) broken English :)
regards from Poland!

Original issue reported on code.google.com by sza...@gmail.com on 5 May 2009 at 11:08

[GoogleCodeExporter]

I disagree. Not changing the extensions would complicate things for most other 
users.

Original comment by bgg...@gmail.com on 31 May 2009 at 8:59

• Changed state: WontFix

[GoogleCodeExporter]

bggmtt:
i doesn't mean not to change extension, but add a new one at the end of 
filename.
this is because winff can not "guess" that e.g. '.mov04' is not an regular file
extension and can not check if he overwrite a source file. 

Original comment by sza...@gmail.com on 1 Jun 2009 at 11:51

[GoogleCodeExporter]

dvgrab outputs ISO dates as YYYY.MM.DD.extension  this seems to totally confuse
winff's output'ed filenames as all similar.
PLEASE!

Original comment by maphill...@gmail.com on 6 Jul 2009 at 3:54

[GoogleCodeExporter]

Matt, I think the latter case has a point, if it is true (If you test for a 
dot, you
should test for the last one.)

As extensions only say so much and are not even compulsory on Linux (not sure 
for
Windows) I would say even the first user has a point, except that you may want 
to
make it configurable. Maybe add a check box or preferences option?

Original comment by poipodec...@hotmail.com on 6 Jul 2009 at 6:49

• Added labels: Priority-Low, Type-Enhancement, Usability
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

winff looks for the first dot from the right. It is essential that the output 
file
have an appropriate extension with out using the '-f' option in ffmpeg.

the other possibility would be to just tack on the extension. For example, 
'test.avi'
would become test.avi.mp4.

Again, this would cause confusion for the vast majority of users.

Original comment by bgg...@gmail.com on 17 Jul 2009 at 2:46

[GoogleCodeExporter]

> the other possibility would be to just tack on the extension. For example,
'test.avi' would become test.avi.mp4.

> Again, this would cause confusion for the vast majority of users.

With this I agree completely.

Original comment by poipodec...@hotmail.com on 17 Jul 2009 at 7:10

[GoogleCodeExporter]

Confusing for most users yes, but it completely breaks multi-dotted filenames 
as they
try to over-write the previous name.  Can we do a last .name1 to .name2 
substitution
instead?

Mike

Original comment by maphill...@gmail.com on 17 Jul 2009 at 11:31

[GoogleCodeExporter]

> Can we do a last .name1 to .name2 substitution instead?

I think this is what Matt thinks WinFF is doing. Do you mean to say that WinFF 
does
NOT check for the first dot from the right? That would indeed be a bug by the 
looks
of it. Although, I can not reproduce that.
Input: dscf0497.1.1.2.avi
Output: dscf0497.1.1.2.wmv

Which is what I would expect. Please let us no if this is not the behavior that 
you see.

Original comment by poipodec...@hotmail.com on 18 Jul 2009 at 8:06