Variables and DOS windows

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' :confused: 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. :unamused:

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

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

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) ?

@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).

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

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) ?[/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:&quot;C:\Program Files\lame\lame.exe&quot; -b 128 &quot;{f}&quot; &quot;.\tmp\{o|ext=mp3}&quot;</instruction> <instruction>@sync:&quot;C:\Program Files\lame\id3cp.exe&quot; &quot;{f}&quot; &quot;.\tmp\{o|ext=mp3}&quot;</instruction> <instruction>Copy MOVE FILE &quot;.\tmp\*&quot; 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...

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

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!

@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

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!

@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 ?
:blush: :blush: :blush:

[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.

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

From the Opus v9.0.0.7 release notes:

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. :slight_smile:

Bob

With the change in 9.0.0.7 that Steje mentions, hopefully @sync is a thing of the past. :slight_smile:

The MultiListers tutorial can be downloaded in a zip file if you don't want to view it online. It's 8.5MB in size so not too bad over dialup I guess. Unless it's really slow dialup. :slight_smile:

For batch image conversion Opus has some built-in functions for doing the basic stuff like resizing and converting to JPG/BMP/GIF/PNG. For doing more advanced things Opus works really well as a front-end to command-line tools like ImageMagick. (There's another good, free command-line image tool but I can't remember the name of it.)

[Encode/Transcode selected WAV/MP3 files to MP3 using LAME)

id3cp would copy every ID3 Tag from any file format I think (you can even copy the ID3 Tag to an empty file which is like a backup :wink:). But I don't know wether ogg/flac use these. I have compiled id3cp from the id3lib package. It was a simple example in it.

Greetings
Ben

Thanks Benjamin. I will try it. It will only (probably) work with ID3 tags, but that is a start.

Some gui-based taggers provide functionality to copy tags universally. Maybe I can find one which supports command-line uhm, commands. :smiley:

Thanks,

Bob

I've tried... TGF and Mp3tag are two pretty good free taggers, and neither of their devs seeme interested in command line or api interfaces.

I expect they feel they put too much time and effort into their UI...

i am using this code for doing transcodes that fit my needs, and it has been getting the job done:

@nofilenamequoting CreateFolder tmp READAUTO=no C:\Program Files\Utilities\lame.exe -b 160 -m j --resample 44.1 "{f}" ".\tmp\{o|ext=mp3}" C:\Program Files\Utilities\id3cp.exe "{f}" ".\tmp\{o|ext=mp3}" Copy MOVE FILE FORCE File ".\tmp\*" TO .\ Delete QUIET tmp

the problem i have run into is that occasionlly, if there is some sort of error and the process quits before finishing, i get left with files that either haven't been transcoded, or if they have, they no longer have any tags since that is one of the final steps. unfortunately, this happened to me near the end of an albums worth of music, so i lost the tags and covers for around 18 of 21 files, and the one it was currently processing was ruined.

a second issue that i have run into is that if i run a search in a folder (with subfolders) and then try to select the results and transcode them with the button, it can't do it. i assume this is because it would normally create the "tmp" folder in the current folder and the files are not technically all in the same folder.

i was wondering was if the coding could be reworked so that new file is created in the same folder, perhaps renamed to have a "~" at the beginning, and then have have the tag copied over, the original deleted, and the "~" removed before moving on to the next file. that way, if something interupts the process, only one file is lost (or needs to be recovered). i would think that would also me to process files in the "Find Results" window.

Collections & flat view

Using .\ doesn't make sense in Find Results since the current directory isn't a real directory (it's the Find Results collection). Using .\ in flat-view will work, though, but it will always point to the lister's current directory, not the directory of each file.

Instead, you can use codes like {f|..} to get the parent of each file. That can be useful when dealing with files in collections and flat view.

I would avoid creating the tmp folder at all and, as you say, use a temp file with a slightly different name. You can use ~{f} to put a ~ at the start of the name. (I guess you still need to be careful in case there's already a file that happens to have that name. :slight_smile: )

Execution order

Any line which inserts a single file will be run multiple times if multiple files are selected. So your command will run this if file1, file2, file3 are selected:

(I've simplified the commands so it's easier to read.)

[code]CreateFolder tmp

lame.exe file1
lame.exe file2
lame.exe file3

id3cp.exe file1
id3cp.exe file2
id3cp.exe file3

Copy tmp* to .
Delete tmp[/code]

If you want the entire command to run for each file before moving on to the next one then you will need to move it into either an external batch file or into an Opus "user command".

You could also put it into a rename VBScript but that would be overkill in this situation so let's ignore that option.

Opus user commands are usually convenient, since everything remains part of your Opus configuration, but in this case I would use a DOS batch file because of the next part:

Error handling

You need to add some flow control to catch errors and deal with them appropriately. Opus commands don't have flow control so you need to move the command into something that does and have Opus call that.

There are lots of options here but in this case using a DOS batch file makes the most sense.

I am assuming that lame.exe and id3cp.exe both set the DOS error code on failure. If they don't then there is no easy way to detect when they go wrong. (With lame.exe you could check for the existence of the output file to detect some errors.)

You can call Opus commands from batch files but, since you're only using CreateFolder, Copy (Move) and Delete there isn't much point in this case; might as well use the DOS commands instead and keep the batch file simple.

In a batch file you can use %1 and %2 to get the first and second arguments, so your batch file would probably look something like this (NOT TESTED):

[code]@echo off

"C:\Program Files\Utilities\lame.exe" -b 160 -m j --resample 44.1 "%~1" "%~dp1~%~n1.mp3"

if errorlevel 1 goto cleanup

"C:\Program Files\Utilities\id3cp.exe" "%~1" "%~dp1~%~n1.mp3"

if errorlevel 1 goto cleanup

del "%~1"

ren "%~dp1~%~n1.mp3" "%~dpn1.mp3"

goto end

:cleanup

del "%~dp1~%~n1.mp3"

:end
[/code]

(See part 9 of Top 10 DOS Batch tips to understand what all the %~dp1 junk means.)

You would then call this batch file from an Opus button, once per file, giving it the path to each file:

"C:\Wherever\You\Put\It\MyBatchFile.bat" {f}

Alternatively...

Having said all of that, I'm going to suggest you don't do any of it. :slight_smile: You can do all of this much better by using a tool that is designed to transcode audio and copy the tags over. I recommend using dbPowerAmp Music Converter (dMC), though I think you may have to pay to get the version that can output MP3 so you might want to explore other options if you want something free.

dMC will convert music from just about any format into just about any other format and it will copy all the tags and cover art (at least for any pair of formats I have tried which support tagging).

You can use it in Opus via the context menus and I find it integrates very well.

It will also encode multiple files in parallel if you have more than one CPU (at least with the non-free version).

And you get a nice overall progress bar and error reporting, unlike when running DOS commands.