Variables and DOS windows

steje · July 12, 2007, 4:25pm

Maybe this will do what AlbatorIV wants:

<?xml version="1.0"?> <button display="both" label_pos="right"> <label>Encode MP3</label> <icon1>12</icon1> <function type="batch"> <instruction>@nofilenamequoting </instruction> <instruction>md "{sourcepath$}tmp"</instruction> <instruction>@set var = {dlgchoose|Select encoding quality:|VBR ~165 kbps (4 - medium)=-V 4 --vbr-new+VBR ~190 kbps (2 - standard)=-V 2 --vbr-new+VBR ~240 kbps (0 - extreme) =-V 0 --vbr-new+CBR 128 kbps=-b 128+CBR 160 kbps=-b 160+CBR 192 kbps=-b 192+CBR 320 kbps=-b 320}</instruction> <instruction>"C:\Program Files\lame\lame.exe" "{$var}" "{filepath$}" "{sourcepath$}tmp\{file$|ext=mp3}"</instruction> <instruction>move "{sourcepath$}tmp\*.*" "{sourcepath$}"</instruction> <instruction>rd /Q "{sourcepath$}tmp"</instruction> </function> </button>
And if you don't want to have to confirm the "moving" of the new re-encoded files and the overwriting of the original files, you can make the move command run move /Y instead...

Edit note: had rd /S - fixed it to say rd /Q to supress confirmation of deleting the tmp directory.

anon94230625 · July 12, 2007, 4:46pm

YES, I'm sure!!!!!! To prove that you can compare the finally posted button with the one posted here yesterday! The only difference is the pause-function, that I included in the final button again because I don't need to close x windows anymore

@AlbatorIV: DO automatically overwrites existing files here! again!

Leo · July 12, 2007, 4:47pm

Ah maybe!

In that case, if you aren't transcoding one MP3 into a different bitrate MP3, then the source and destination will have different file extensions so you can do the conversion and then delete the source easily enough.

On the other hand, if you are transcoding from one MP3 bitrate to another then you're doing something wrong and evil and harmful to the quality of your audio.

steje · July 12, 2007, 7:46pm

True, for some reason I thought the ppl asking these questions were in fact transcoding/re-encoding from a 'higher' bitrate to a lower one...

As far as what AlbatorIV is 'actually' looking for - let's get it straight from the horses mouth... Albator... what say you my friend?

anon94230625 · July 12, 2007, 10:11pm

Yes, in the very first posting I told about re-encoding directly to MP3-Player (I don't need bitrates higher than 160-192kbps!).

AlbatorV · July 13, 2007, 8:39am

it's perfect
i have just modified some things

<?xml version="1.0"?> <button display="both" label_pos="right"> <label>Encode MP3 (128)</label> <icon1>12</icon1> <function type="batch"> <instruction>@set br = "-b 128" 'CBR 128 kbps</instruction> <instruction>CreateFolder {sourcepath}\tmp READAUTO=no </instruction> <instruction>@set dest = "{sourcepath}\tmp"</instruction> <instruction>md "{$dest}"</instruction> <instruction>"/home\Viewers\lame3.97\lame.exe" "{$br}" "{filepath$}" "{$dest}\{file$|ext=mp3}"</instruction> <instruction>"/home\Viewers\lame3.97\id3cp.exe" "{filepath$}" "{$dest}\{file$|ext=mp3}"</instruction> <instruction>move "{$dest}\*.*" "{sourcepath$}"</instruction> <instruction>rd /Q "{$dest}"</instruction> </function> </button>

BobA · July 13, 2007, 8:48am

I have been tinkering a lot now and then with my audio-transcoding, and some other functions related to audio formats. I am finding, more and more, that button/context-menu/drop actions behave differently, dependent on some circumstances which I have not figured out. I've had everything working wonderfully one day, and gone back the next, and things don't work the same way, or at all. I think one possibility may be whether there is another lister open somewhere.

What @sync does, is to cause ten (example) conversions to take place synchronously, instead of opening ten console windows at once. It also (and for what reason I do not know) along with using 'dopusrt /cmd...' on certain commands, presents a progress bar with an abort button, which is very desirable to closing ten console windows (if they are not hidden, even) if you realize you've made a mistake.

I haven't tried passing all the source files to LAME at once, I don't believe. The fact that others are having discrepancies in the way things work, bears me out, I think.

I may post my work soon, even if I'm not totally satisfied that it is working in a consistent manner. Maybe some others can help me figure out what is going on.

To make this post 'worthwhile' I'll ask this question: Does {destpath$} always point to a path? Only when there is a destination file display open? Under what circumstances? DOpus was presenting a folder selection dialog for me, for a long time, when using:
dopusrt /cmd go {destpath$} openindual

if the lister was not in dual mode. Suddently, one day, it decided there was a nice path it would just go to on it's own. I worked with it for an hour, only to put the original code back in place, and have it begin to present the dialog again.

Most recently, I am seeing code which hasn't been changed, begin to open new lister windows. Why, I do not know.

Thanks so much,

Bob

BobA · July 13, 2007, 8:54am

I just tried the button code from the post before mine. It (not causing any harm at all) wreaks havoc here. It creates two (temp?) folders, flashes a console window, and exits.

I had one mp3 selected, in the source lister.

I am guessing that various combinations of listers and lister states, cause differing results.

Best,

Bob

AlbatorV · July 13, 2007, 9:13am

did you change this path to your : "/home\Viewers\lame3.97\lame.exe" ?
did you download the file "id3cp.exe" in this thread [Encode/Transcode selected WAV/MP3 files to MP3 using LAME - #3 by BenjaminW) ?

Leo · July 13, 2007, 9:33am

@sync doesn't do that.

If you run 10 external commands then they'll always be run one after another, whether or not you use @sync.

@sync is only relevant if you are mixing internal and external commands. In the current version of Opus, if you don't put @sync before external commands then they may be run in parallel with internal commands, but none of the examples in this thread use any internal commands so @sync isn't relevant here.

It's looking like the next version of Opus will finally make @sync the default so that you no longer need it. I think this will be far more sensible as people generally expect a list of commands to be run in series.

{destpath$} path will turn into the destination file display's path, if there is a destination file display. If there isn't one then {destpath$} will cause you to be prompted for a destination directory that the function will work with. Because of the $ at the end the {destpath$} code means "NEED destination path".

If you use {destpath} ("WANT destination path") instead then it will turn into the destination path if there is one and into an empty string if there isn't one, without prompting you.

You must have had another lister window open. Source and destination are not restricted to the two sides of a dual-display lister. If you have two single-display lister windows open then one will be a source and the other a destination. There's a video in the Tutorials section which expains how all of this works:

[Working with multiple Opus windows/listers (video tutorial))

It might be as a result of using "dopusrt /cmd" before your Go commands. If you're using Opus 9 you should remove the "dopusrt /cmd" stuff and, at least until the next version, prefix all external command lines with @sync if you are mixing external commands (e.g. lame.exe) with internal commands (e.g. Go).

BobA · July 13, 2007, 10:43am

I'm sorry, I'm not very skilled with the quoting in the forums.

I believe I have my functions working now. At least they work here.

What the intended effects of some of the commands and symbols are, and what side-effects they may cause, can be different things. I very much want the progress dialog, more for the abort button than anything.

go {destpath$} dualpath

for some reason inhibits the progress bar dialog, unless preceded by

dopusrt /cmd.

I am aware that the destination path can be in another lister, but not understanding how to tell which other lister, and why a specific path may be opened in the right view when it is not displayed in any lister, nor chosen. Possibly, relying on the described outcome is not good, if circumstances can change that outcome.

My actions deal with seven or eight codecs, I'm not sure if anyone here has many different file formats. You can convert from wave, everyone has those.

I have uploaded my toolbar and filetype setting for Lossless Audio, if anyone cares to look into it, they are at:

http://deepelem.us/AudioBar.dop

http://deepelem.us/LosslessAudioFormats.dft

I do not have any type of documentation, really. You can convert from
FLAC, APE, SHN, WAV
to any of those, plus
mp3, ogg vorbis, and m4a

By default the resultant files go to the destination lister. If there is not one, a dialog should appear to allow you to choose one, and open it. If you want to convert to the same (source) folder, hold down [shift] while clicking a button or a menu item.

I think the best way, is to right-click and drag the files to be converted. They will output to whatever path you drag them to, even the source.

In all cases, you should get a progress dialog, and the console windows are minimized, not hidden.

I'd really like to ask some questions and understand some things, better, if anyone has time to look at it, especially if there are better ways to achieve these goals. Tags are rarely preserved.

The codecs, etc, are in a file at http://deepelem.us/opus/audiobar/4sound.zip Please don't use anything in that file besides the codecs, which go into your Windows folder. The other stuff has older versions. Most audio codecs which are free can be also found at http://rarewares.org

I had really hoped to present something in a better manner than this, but becoming very frustrated, mostly with myself. With some interest from someone else, working with audio files could be done very nicely through Opus.

Thanks,

Bob

steje · July 13, 2007, 6:11pm

did you change this path to your : "/home\Viewers\lame3.97\lame.exe" ?
did you download the file "id3cp.exe" in this thread [Encode/Transcode selected WAV/MP3 files to MP3 using LAME - #3 by BenjaminW) ?[/quote]
A few comments about the commands in the button from AlbatorIV (just my thoughts and tastes pal... not meant for "criticsm"):

@set br = "-b 128" 'CBR 128 kbps
...since you're setting {$br} to a static value and then only using it once down below, it's probably a little overkill to bother setting the value as a variable... and I'm not sure what the 'CBR 128 kbps is at the end either... a "comment" perhaps? Is that part of the variable just getting ignored by lame?
CreateFolder {sourcepath}\tmp READAUTO=no
...cool
@set dest = "{sourcepath}\tmp"
...same thing here... since you're only assigning a static value
md "{$dest}"
...not sure what's going on here, didn't we already create this folder up above?
"/home\Viewers\lame3.97\lame.exe" "{$br}" "{filepath$}" "{$dest}{file$|ext=mp3}"
"/home\Viewers\lame3.97\id3cp.exe" "{filepath$}" "{$dest}{file$|ext=mp3}"
move "{$dest}*.*" "{sourcepath$}"
rd /Q "{$dest}"

To satisfy my personal cleanliness peaves, I would probably do it like this, and not as a 'batch command' type:

<?xml version="1.0"?> <button display="both" label_pos="right"> <label>Encode MP3 (128)</label> <icon1>12</icon1> <function type="normal"> <instruction>@nofilenamequoting</instruction> <instruction>CreateFolder tmp READAUTO=no</instruction> <instruction>@sync:"C:\Program Files\lame\lame.exe" -b 128 "{f}" ".\tmp\{o|ext=mp3}"</instruction> <instruction>@sync:"C:\Program Files\lame\id3cp.exe" "{f}" ".\tmp\{o|ext=mp3}"</instruction> <instruction>Copy MOVE FILE ".\tmp\*" TO .\</instruction> <instruction>Delete tmp</instruction> </function> </button>
This uses all Opus functions except for the lame and id3cp program calls, and shows the use of @sync to run the two external apps in series...

BobA · July 14, 2007, 5:54am

I'd like to humbly apologize to all, especially Nudel, for my previous post. It is not generally characteristic of me.

I've tried working with this thing quite a bit, and run into a lot of confusion. My concentration and memory lately are at a low. I would do better, I think, to ask questions when I do not understand, than to struggle to 'get everything perfect' all on my own.

I did, really, want to contribute something, and music (listening) (and working with music files) is a great love of mine. I realize there are tools for doing what I am doing (free ones, even) better than this way, but as I see it, DOpus makes for the Ultimate Shell for audio transcoding and several other functions provided commonly by console apps. The same goes for other conversions and functions (such as the PNGTools toolbar).

I'd like to be a good member of the community, and hope to be able to contribute a bit here and there. Apologies (and embarrassment!).

Bob

steje · July 15, 2007, 1:05am

Hi there BobA... unless I've missed something, I think you're being a tad hard on yourself. With 8 posts to your name as of this writing, wanting to contribute at all is laudable... and will come in time as you learn more about Opus. Opus is a program that gets a lot of criticism for having a tough learning curve...

So... I would say that you ask away whenever you have questions and just try to be as clear and specific about:

what you want to do
how you might be trying to do it already
what do you expect to happen
exactly what seems to be going wrong or not as you'd expected

I'll take a peek at your toolbar sometime this weekend and post my thoughts (in between bottles of Yuengling).

Cheers!

David · July 15, 2007, 1:20am

@nudel

Yes,
DOpus suffers terribly from an inability to run a general sequence of DOpus Commands.
The simple answer is to be specific about the exact command you want.
In other words, a complex one line command works Great.
The idea I use most often is simply to be certain that any sequence of Directory Opus commands I use work fine if all are run simultaneously.
There are known exceptions and tricks such as time delays.
Personally, I don't care for time delay techniques.
I'd rather hack a work around solution I know I can trust.

So I must ask, do you also mean that internal commands will be run in series by default ?
Just asking .... not expecting a miracle here.
It's not just Directory Opus I know.

Well, to my point.
The most obvious Directory Opus Commands that benefit from being run
asychronously are Copy and Copy Move.
It's far better to let copy progress dialogs keep poping up ( maybe we'll even get a copy que function in a future version ) than to wait for DOS to copy each file synchronously .

I don't mean to get off topic here, I just wanted to fill in a crack.
And I wanted to say to BobA that he's doing just fine.

Bob, try researching some of my old posts.
Now there is some true embarassment there.
Bob, you're not even close to posting something embarassing here !

Opps.... I see Steje has posted now ...
Howdy Steje !
Have you ever made an "embarassing" post ??????

Zippo

Leo · July 15, 2007, 5:21pm

Have a watch of the tutorial video I linked in my previous post in this thread. It should help you understand all of that. It mentions how to tell when windows are in Source and Destination modes.

I'm not sure why the Go command would prevent the progress dialog from appearing. It could be an unexpected side-effect or even a bug. Might be worth dropping a message to GPSoft (via gpsoft.com.au/Support.html) with an example command that demonstrates the problem so that they can take a look at it.

Your posts are all fine, too. No need to apologise!

David · July 15, 2007, 11:21pm

@Nudel
Nudel, after some more thought, I must offer my humble apologies.
I did not intend at all to offend .
I wrote something that once made sense to me.
I remember a DOS copy being very slow as compared to a series of Dopusrt /cmd copies in a a script I once wrote.

Well it still does make sense to me in batch files.
It can be better to start a copy using dopusrt /cmd and move on in the batch file rather than wait for DOS to complete the copy.
I remember the DOS copy as being much slower.
I'll dig into in a bit deeper to find out if I'm totally off base here.

I am beginnig to see things in a different light now.
I wrote:

[quote]The most obvious Directory Opus Commands that benefit from being run
asychronously are Copy and Copy Move.
It's far better to let copy progress dialogs keep poping up ( maybe we'll even get a copy que function in a future version ) than to wait for DOS to copy each file synchronously . [/quote]

Well actually both on Win98 and Vista DOpus copy commands get enqued into one when run as a DOpus function.
They run very fast.
I had thought internal commands ran asychonously in separate threads.

Prepending the copy commands with dopusrt /cmd runs them separately.
Alternatively, separately drag and drop two big copy operations.
However, the copy speeds of two such simultaneous copy operations are much, much slower than half the speed of the enqued copy operations on both Win98 and Vista.

Ths is contrary to what I would have expected on Vista.
I mean, I'm running a Dual Core processor, and Quad Cores are on the horizon !
Wouldn't it make sense that multiple copy windows complete faster than a single enqued copy window on these machines ?

Well, I hope I'm still at least a little on topic to this thread.

@ Bob
See how embarassing it can be ?

Leo · July 16, 2007, 8:36am

[quote="Zippo"]I mean, I'm running a Dual Core processor, and Quad Cores are on the horizon !
Wouldn't it make sense that multiple copy windows complete faster than a single enqued copy window on these machines ?[/quote]
Dual CPU doesn't make every parallel operation faster.

Copying files uses very little CPU (unless there is a poor network card driver or anti-virus program using up a lot of CPU).

If you do two file copies at once on the same physical drive then it will be much, much slower because the disk heads have to keep seeking back and forth between the two bits of data that are being read (and the other two that are being written if the destinations are also on that drive).

Even if the two copies are not on the same drive there will be a bit of competition for the system bus, although copying in parallel with two independent drives will probably still be faster than doing it in series, depending on the system.

steje · July 16, 2007, 6:28pm

From Leo's keyboard to our pc's... (actually "jon's keyboard' eh ):

From the Opus v9.0.0.7 release notes:

• In Opus functions that launch external programs, the default behaviour until now has been for all external programs to be run asynchronously unless prefixed with @sync:. This has now changed - the default now is for all external programs to be run synchronously. For example, in a function that has an external program followed by an internal command, the second command will not be run until the external program has completed. The old @sync: prefix still works but is now effectively ignored, and there is a new @async: prefix which provides the opposite behaviour - that is, a program prefixed with @async: will be launched asynchronously. There is also a new flag in Preferences / Miscellaneous / Advanced called 'function_default_async' which lets you revert to the previous default behaviour if desired.

BobA · July 17, 2007, 5:22pm

Thank You All. I'm a bit of an overly-sensitive person.

I will post some code snippets regarding the @sync (command?) if I verify that I am correct (or even incorrect!).

Maybe I do expect too much from myself, as I expect perfection. Hah!

DOpus is indeed complex and can be confusing. I have looked at some of your tutorial, Leo, but not a video. Is it viable for someone on dialup?

The way I see it (may have said this already)... I know of one program (freeware) which is explicitly for the purpose of being a front-end/manager for audio-file formats for which the encoders and tools either are command-line, or can be (such as flac.exe). I certainly hope that person is not on this forum... it is an invaluable tool, but with much less work, I have been able to recreate that program, using DOpus as the shell. My version using DOpus is FAR easier to use than that program's interface.

I think there are probably other command-line tools for processing files, for which DOpus could become the ultimate front-end/shell. I don't know a lot about Irfanview, but I know it does many batch processes from the command-line, for image files.

I'm very appreciative of everyone's kindness.

Bob