Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: general frontend (Read 4390 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

general frontend

I'm looking for a general frontend. I mean it would be configured like in EAC "User defined" encoder, so the program would never be outdated, since with any change in any command-line encoder, you could change the settings. I think it would be very nice to have such a "general frontend". maybe it would never be updated, unless by bug-fixing or for adding new functionalities. oh yeah, and this program would be for decoding too. well, for anything you want

general frontend

Reply #1
nobody interested in doing the prog?
maybe speek/john33 can do it?  Or not? 
one more time, it would be very useful

general frontend

Reply #2
The user would have to reconfigure things everytime he uses another encoder. I don't think that would be very handy.

general frontend

Reply #3
yeah, while under the shower, I've thought about this. So the solution: you can save the settings for each encoder you want. In a drop-down menu, you choose what encoder you want to use. And you always can edit the settings and add/remove encoders/decoders.  I think with some discussion we can get a great program.

general frontend

Reply #4
Hmm, could be nice. But it would be much to difficult for me to program. My frontends are just modifications of vbLamer and that's about all the programming I'm capable of.

general frontend

Reply #5
while navigating the board, another inspiration from EAC: the program could use profiles for each encoder, like the profiles for cd-roms in EAC.

general frontend

Reply #6
If there is enough demand for this utility, I might be willing to make something like this... But I'm not sure how many people would want it.

general frontend

Reply #7
Quote
Originally posted by NickSD
If there is enough demand for this utility, I might be willing to make something like this... But I'm not sure how many people would want it.


me

cheers,

general frontend

Reply #8
I believe a universal frontend written in java was planned by Dibrom and sphoid. Perhaps you should check with them, there's little point to having a multitude of frontends.

general frontend

Reply #9
I got it all thought out... but I can't code


(under 'Options' only general options: application priority, beeping after completion, output logging)



I guess this is not really what Dibrom intended, yet it would be a very usefull app in my opinion. NickSD, every other coder out there, what do you think of it??

All apologies to Holger Dors for the shameless interface rip - once somebody starts coding, I'd be more than happy to create fresh icons.


ephemeros

general frontend

Reply #10
this is what i was thinking about. well, surely, it would have some changes.....
and atherean, I think the general encoder frontend which you talked about is the set of tools being created for the Hydrogen Audio Tools.
it will have ABX and other things, and I think many users don't want ABX, just a frontend for all encoders/decoders.
well, Dibrom and sphoid can correct this if I'm wrong.

general frontend

Reply #11
Quote
Originally posted by ephemeros
I got it all thought out... but I can't code

ephemeros


Good work there in creating screenshots of something that doesn't exist .  It looks promising, but as mentioned before, I wouldn't want to start developing something that someone else is already working on (Dibrom, et al), if that is in fact the case.  However, if it turns out that no one is really working on anything too similar to this, I'll start working on it - I could probably get something out in a week or two since I'm fairly busy at the moment.

BTW, nice R.E.M. reference  -- Automatic for the People is a great album.

Nick

general frontend

Reply #12
A thing like this is something I have really been looking forward to!

general frontend

Reply #13
Actually, I'm working on a similar frontend. It will have choices for predefined presets for each encoder and will also allow custom switches. For MP3, it will run FhG (mp3enc & fastenc), LAME & GoGo. For AAC it will run PsyTEL (aacenc and fastenc) and FAAC. For Lossless it will run FLAC, WavPack (lossless & lossy), and Shorten. And of course OGG and MPC.

general frontend

Reply #14
glad you guys like it:)
All my life (well, not quite) I've been looking for something to create easily batch processes on filelists...

L3M, how far are you from completion?
Maybe Dibrom/sphoid could enlighten us on their project?

Nick, thx! If the other projects turn out to be slacking, please go ahead! I'll be your first beta-tester:D



ephemeros

general frontend

Reply #15
Yes, sphoid and I are working on something similar to this.  We have had plans for this for quite some time actually, at least a few months, but until recently have not had the time to really work on this.

This is the next item sphoid and I plan to release after the ABC/HR utility which is just about ready for a beta.. everything is mostly finished, we are just fixing up the interface some and attempting bug fixing.

There has actually been some work done on this utility but it has been on hold for awhile.  I plan to resume development this week, as soon as a beta version of our ABC/HR utility is out.  I should be able to show an example interface here pretty soon.  In fact, the LAME interface and gui module is mostly completed.

The idea for the frontend we are planning is fairly advanced.  Of course it will be generic and support multiple formats, all fully configurable as well as supporting some sort of scripted interfaces and reconfigurable guis.  Basically the frontend will eventually provide an extensible framework via XML/XUL (based on the same technology as the other tools will be) so that format descriptions (interfaces and guis) can be added externally without having to be compiled in.  There will also be support for intermediate processing in the form of external utilities like replaygain, ssrc, etc.. and the plan is to eventually tie the program into the other utilities and release the entire thing as a suite of tools.

In addition to all of this, the frontend will be cross platform and should run on windows, linux, mac, bsd, etc..

general frontend

Reply #16
Quote
Originally posted by Dibrom
In addition to all of this, the frontend will be cross platform and should run on windows, linux, mac, bsd, etc..
I'm curious as to how you plan to accomplish that.  Are you going to solve the cross-platform GUI problem by writing your own GUI widgets (like Mozilla does), or are you going to do something like code in GTK+ and then make the Windows people download the GTK dlls?

general frontend

Reply #17
Quote
Originally posted by Delirium
I'm curious as to how you plan to accomplish that.  Are you going to solve the cross-platform GUI problem by writing your own GUI widgets (like Mozilla does), or are you going to do something like code in GTK+ and then make the Windows people download the GTK dlls?


Java, maybe?

general frontend

Reply #18
Quote
Java, maybe?


Bingo. We will be using swing  + XUL/XML to provide GUIs for most of our programs... which of course will be skinnable. Initial versions will probably be skinnable with gtk and Kde themes. As far as the guts of the program go however, we are hoping to use JNI interfacing to provide the most robust functionality by using the native libraries to do the work, therefore if you feel that the fact that we are using java is a stigma, rest at ease . Additionally, as part of the Hydrogen Architecture , it will eventually be able to autodetect the OS and grab the appropriate codec online so that the user will not even need any codecs installed in order to use our software. There is still alot of foundation to lay though so full functionality will only come with time. Im still chugging away with Blind Audio so as soon as that is finished i can help Dibrom on the front end... stay tuned.

general frontend

Reply #19
Quote
Originally posted by sphoid
Bingo. We will be using swing  + XUL/XML to provide GUIs for most of our programs... which of course will be skinnable. Initial versions will probably be skinnable with gtk and Kde themes. As far as the guts of the program go however, we are hoping to use JNI interfacing to provide the most robust functionality by using the native libraries to do the work, therefore if you feel that the fact that we are using java is a stigma, rest at ease . Additionally, as part of the Hydrogen Architecture , it will eventually be able to autodetect the OS and grab the appropriate codec online so that the user will not even need any codecs installed in order to use our software. There is still alot of foundation to lay though so full functionality will only come with time. Im still chugging away with Blind Audio so as soon as that is finished i can help Dibrom on the front end... stay tuned.
Sounds excellent; looking forward to seeing what comes out of it.

If you need any help with testing or coding (I mainly do C++ and C, but a bit of Java) let me know, though I'm sure most of the forum would be willing to help as well.  I also have access to a Sparc Solaris server to test things on if you want to do some cross-platform tests (as well as my normal win2k box, but you guys probably have those yourselves).

general frontend

Reply #20
and if you want me to test it in my win 3.1 system, it's ok.

ps: just jokin

 

general frontend

Reply #21
Quote
Originally posted by Var Gaals
and if you want me to test it in my win 3.1 system, it's ok. 
ps: just jokin


Well, we DO have Win3.11 in some computers at my University. (386 and 486, mostly)
But I really doubt Sun released latest JRE supporting Win16

 
SimplePortal 1.0.0 RC1 © 2008-2021