New Tool (3.0): ReLame Mp3 encoder

xterm was not installed. I installed xterm in Mint 15 and now it works! Nice solution to see the mp3 encoding. Thanks again!

This version, based on the Linux/Mac .xrnx above, handles VBR as well as CBR.

Okay no problem Tom, smashing that it works for you :)

You’ve also got VBR support from Monotreme Goat now :)

VBR support too!
Its getting better and better :walkman:

I hope so. See attached for even more betterness - at least I hope it is ;)/>/>/>

4558 ReLame gui 20140117.png

Title and Artist are pulled from the song comments.

If the song’s been saved (as an .xrns) then the default location will be that folder and name (only with .mp3 instead of .xrns).

The Song Dir button sets the destination directory to the folder containing the .xrns file, for when you change your mind, having Browsed to another folder…

Persists options across a session, where sensible to do so. So you choose VBR 0 and that stays even when you load up a different or new song. Your choice of destination persists only whilst editing the same song.

Persistence between sessions should be easy, but I’ve not implemented it yet.

I’ve not tested this on Windows (yet) or Mac (Apple free zone), but it should just work if the Lame binaries are present when ReLame expects them to be.

Super Monotreme :)

Some things I should of done. Trackid value (or track number in lame) can be 1-255. However from the lame help:

So optionally a total number of tracks can also be given in that field. Lines 490 and 586 really need modifying to reflect this (with a little error checking preferably.)

The only other thing is cross platform dependency with the lame program itself. I personally use Linux so I can’t test either Windows or Mac. If we look at line 604 which I think takes the path of the Windows Lame binary from the tool directory and expects lame.exe to be sitting there. Soundb3ast originally supplied a Windows binary (which I think was a 64-bit executable version) wrapped up with the tool zip (hence the download size), but that would not work under a 32-bit Windows XP for example. All in all I suppose it would be up to the user to grab a lame binary for Windows and to place it into the ReLame tool directory manually.
Mac OS X. No idea what the command line would be.

Just add some OGG support with oggenc but you may have to alter the tool name. Or do a seperate tool called ReOgg :)

I was wondering about cross-platform path searching. If the tool can’t find Lame it could prompt the user for the path.

Me either, but Mac’s just Unix … right? :) Someone on IRC will know…

It would save duplication of common code to keep them in a single tool. Toggling visibility of encoder specific panels is easy enough, as is constructing variant cmd strings.

The name’s a toughie though ;)

Hmmn… ReCompression?

Yup, check the tool directory, if not found prompt user for the lame binary path. A possible binary download for Windows could be → RareWares - LAME Bundles

Exactly what I thought, hence why I tied both Linux and Mac OS X together command line wise. But, questions: does Mac OS X have an xterm installed by default?*** What is this Terminal.app program (Terminal (macOS) - Wikipedia)? If it only has Terminal.app, how do you use it to execute lame as a wrapper? Terminal.app --command ‘lame …etc…’?? Hmm.

Ah, ReCompression. Yes if you added in OGG support into the one tool I’m sure that would be great. You would have to ask Soundb3ast however :)

*** Just as a final thought to keep in mind wth Linux. Under most modern distros xterm is not installed by default. You have gnome-terminal, konsole etc… pretty much everything other than a plain simple xterm. I hardwired it to xterm to make it as simple as possible. I considered using $TERM which would execute the default terminal the user has. But does the terminal use -e or --execute or something else? Luckily most terminals support -e so changing xterm to $TERM is feasible for most people. But no doubt there is always going to be someone who is using some strange wacko terminal that doesn’t support -e or --execute :)

Nice updates guys!

http://www.pcworld.com/article/148631/article.html indicates that Leopard did. But that article is old, so may be OOD?

I’m not at all bothered by the name, as long as potential users can find the tool if they need it, which they’ll do by searching for “mp3”.

If they’re running that weird a terminal, they can probably write a wrapper script for it themselves to process the CLAs?

I was planning on implementing a “Run in terminal” option. In fact I might just go off and have another tinker now…

I’ve got it producing Oggs, and have the gui in place for MBR and VBR for Oggs. Just need to implement the production of appropriate command-line switches and I’ll pop up a fresh .xrnx.

I’m AFK for a while, so it’ll be a couple of days before I’ve had time to implement and test.

I’ve added ABR for mp3s for completeness. (Does anyone ever use ABR?)

With the refactoring for the above, it should now be a lot simpler to add further formats/encoders if desired.

I’ve put that option in place, and another for holding the xterm open after it’s finished. No gui for either yet - I’ve been getting to grips with some of LUA’s idiosyncracies (i.e. head repeatedly meets wall).

Must get round to implementing config persistence…

More betterness.

There are Options. Options for encoder paths. Options (on Linux and Mac) for terminal related tinkering.

There are more types of bitrate than a stick can be shaken at.

There’s a new menu item to re-render to .mp3/.ogg without bringing up the dialog box.

Your choices and options are now persistent.

As on my previous updates: it’s designed for use on all three Renoise supported platforms, but has so far only been tested on Linux.

This one won’t work on Windows, will work on Linux, and probably will work on Mac.

Thanks for the updated version! Looks nice.

I get an error when I open the tool from the file menu and press cancel.

‘/home/tom/.renoise/V3.0.0/Scripts/Tools/com.soundb3ast.ReLame.xrnx/’ failed to execute in one of its menu entry functions.

Please contact the author (SoundB3ast) for assistance…

std::logic_error: ‘custom_dialog: expected a valid, visible content view.’
stack traceback:
[C]: in function ‘show_custom_prompt’
main.lua:780: in function ‘ReLameGUI’
main.lua:949: in function main.lua:949

When I open the tool for the first time, I set the save path to /home/tom/Downloads.
But when I reopen the tool I have to set the save path again. The previous path is not persistent.

@Tom: thanks. I’ve fixed the first problem.

The second is kind of by design - I’d figured that the .mp3/.ogg would go in the same folder as the .xrns. Maybe this would be better set as an option since different people will have different expectations here.

I’ve done some testing on Windows 7 and will upload a new version when I’ve finalised the changes that that is necessitating.

Okay, 'nother new version. This one has been tested on Windows 7, found wanting, recoded some more, tested again on Win7 and Linux, and here it is.

4575 ReLame Main.png

I’ve attached the version with no binaries and put the one with Windows binaries (Lame and OggEnc) up on gdrive:

https://drive.google.com/folderview?id=0B7VeuOYUNNWLVTFhNUlNbmFIMFk

Any problems or suggestions, please do let me know.

Thanks for the new version. The tool is working fine now, the error is fixed and the path for saving files is persistent now.

I got this error (Windows 8.1)

‘C:\Users\South\AppData\Roaming\Renoise\V3.0.0\Scripts\Tools\com.soundb3ast.ReLame.xrnx\main.lua’ failed in one of its notifiers.

Please contact the author (SoundB3ast) for assistance…

main.lua:369: bad argument #5 to ‘format’ (string expected, got nil)
stack traceback:
[C]: in function ‘format’
main.lua:369: in function ‘Render_Track_WAV2MP3’
main.lua:313: in function main.lua:313

Didn’t work for me in Win 8.1 as well :frowning:

Thanks for this, some how never came across this tool before, works fantastically.