On 2/8/06, Morten Nilsen <[EMAIL PROTECTED]> wrote: > > > > I can't put spaces in format, they get stripped, and output files have > > spaces replaced with _ in artist/track name .. bad, very bad.
For now, we replace all spaces with _ , we might want to simply escape them later on. > > other than that and the text bug I mentioned earlier, lovely program :) Thanks (= > I made me an awk script some time back that does ripping the way I like > it, only it requires manually written track lists.. > Now, the script generated commands like (all on one line); > > cdparanoia -q 01 - | oggenc -l 'Hate' -N 01 -a 'The Delgados' -t 'The > Light Before We Land' -o '[01] The Delgados - The Light Before We > Land.ogg' - > > and oggenc is then nice enough to show a progress of encoding the track > as it's ripped.. now, I notice extrackt doesn't use oggencs progress > report.. why not? Extrackt is very modular. It does not assume anything about your encoder / ripper and the backend and frontend are completely seperate and communicate using message passing. So you can have any combination of ripper, encoder, and frontend (Etk, Ewl, Gtk, curses ...) Given that, we cant support any specific extentions for the progress bars. The ripping progress bar works by calculating the projected file size for the wav, and stat()'ing the current file, and showing a percentage. The encoder progress bar can only do the same if it knows the bitrate you're using, and if you're using variable bitrate, then it can do that without communicating with the encoder. This is done in a lot of apps in a hacked way where they either have soecific support for an encoder, or force the user to enter the bitrate into the app itself. Since Extrackt doesnt know the bitrate (its part of the options you set in the encoder's template, like -b 192 or whatever the encoder supports), then it can not make any conclusions regarding that matter. Reading specific output or depending on a specific progress report from the encoder also can not be done as it requires C code specific to that encoder. Extrackt simply has templates that define a general executable, being a ripper or encoder. It has the name, exe, and flags, and file format. That way we gaurantee it works with anything you supply. A template creator should be available soon so you can add your own encoder / ripper. > True, some people with slow computers might prefer to not encode > on-the-fly, but realistically, how many would that be? > > I think making on-the-fly encoding at least an option, and maybe default > on would be a good idea :) This also depends on the ripper and encoder writing to and reading from stdin and stdout respectively if I'm not mistaken. This might become an option at some time, but I'm not so sure about it as it would require assumptions. For now, we'll stick with writing wavs, and encoding them, but looking into that is something we can do when all the bugs are sorted out. Thanks for you input! (= hisham. -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
