RE: re-encode tool win32

Frank Russo <[email protected]>
Newsgroups gmane.comp.audio.compression.flac.user
Message-ID <[email protected]>
To answer the original question, I do not believe that there is.

What may be an eloquent solution to this problem is to start a collection of "Flac tools" on sourceforge.  These could be command line or gui utilitis, and would reside in a single permanent location.  This way we could have actual sh/bat files with proper error checking and such rather than one liners.  Back in my windows days, it would take me all of 5-10 minutes to wrap a command line (like the ms example I came up with from  /? instructions only) in a VB6 gui app.  I am certain that someone with similar new age .net skills probably reads the list, and might not mind doing the same.

As for the scripting skill level thing, I did not mean to suggest that computer users would be capable of such a feat.  By "basic command of a **IX shell" I meant that they were on the second semester of a scripting 101 course or had completed "scripting for dummies".  Once you learn what tools are available (how to loop/iterate, how to nest commands, etc) the rest is just chaining the tools together in a linear fashion to achieve the desired result.

Someone put together a tools page, maybe split out flacGUI from the core flac project, and we'll all do our best to extend the tools to make common tasks easier for the users.

Frank

> Date: Sat, 29 Sep 2007 01:06:03 +0200
> From: [email protected]
> To: [email protected]
> Subject: Re: [flac] re-encode tool win32
> CC: [email protected]; [email protected]
> 
> but to return to my original question: is there a graphical tool to
> re-encode directories (and subdir's inside of them) for win32?
> 
> because otherwise windows are still 'stuck' when they want to do that.
> I agree entering such long command line strings is not user friendly,
> so i'm looking for a tool if this exists
> 
> thx for your attention
> 
> 2007/9/29, Aaron Whitehouse <[email protected]>:
> > > anyone who has a basic command of an **IX shell is more
> > > than capable of one-lining most find/search/sort/exec tasks.
> >
> > That is overstating things a little. I have been using Linux for about
> > five years and I wouldn't have come up with that command on my own.
> >
> > That said, I agree that Josh is better to spend his time writing the
> > encoder (which he does incredibly well). I guess that people who want
> > to do this will find it out eventually :). With any luck, third party
> > tools will step in to provide this kind of functionality, in a
> > user-friendly manner, without distracting Josh. The same argument
> > could be said for the windows FLAC gui - is it just a "distraction"
> > from the core job of upgrading the encoder?
> >
> > To be fair, if it is really that simple, someone that isn't up to
> > working on the encoder could add this feature and Josh wouldn't be
> > distracted at all. There would be no need to "re-implement or maintain
> > "dir", "grep", or "find" equivs in flac" as they could depend on the
> > existing tools. It would not be desirable for the base Flac libraries
> > to depend on these things, however, so I agree that it probably
> > belongs somewhere else.
> >
> > This is all just rambling, really. I now have the answer and can
> > happily use it. I just get annoyed when people tell me that your
> > average simple user could come up with a long command string when, in
> > actual fact, the majority of computer users don't ever see a command
> > line.
> >
> > Thanks for your help,
> >
> > Aaron
> >

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

_______________________________________________
Flac mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/flac
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.