oggdropXPdV1.6 beta 14 is available at Mirror 1. It is available in normal and P4 flavours and with or without lossless decoding support. If you are downloading the versions with lossless support, you MUST download the lossless dlls again, otherwise FLAC decoding will not work. FLAC is only one dll now, you can delete the 'grabbag' and 'gain_analysis' dlls.

New feature: when selecting a different output directory to the input (default) directory, the new directory will be created if it doesn't already exist.

Groovy

I wonder, could it be possible also to have ODropXPd create folders when renaming tagged files.

Example:

%1 = Artist
%2 = Album
%3 = Number
%4 = Title

and then having a renaming scheme like
%1 - %2\%3 - %4

make OggDropXpd
create the folder "Artist - Album" and put the renamed files in that album with the naming "Number - Title"?

Hope you understand what I mean

1) When I "Appply a Scale Factor of:" 0.001 program does not store this setting. With 0.0001 program says: "will leave wolume UNCHANGED" and does not store this setting. I know, these settings are useless.

2) Why no "pre-1.1" versions?

3) Is there any chance for AMD Athlon otimization?

OGGdropXP rulez for me. Keep Good work

I fear I've opened up Pandora's box.

These are percentages, so 0.001% is not even worth considering, is it??

There is so little difference and they are not really for archiving that it's not worth doing.

The normal version is optimised for PIII/Athlon already.

Not really, John. As I said above, the normal compiles are already optimised for PIII/Athlon anyway!!

THX for info.

Yes, so maybe disable 0.001% and 0.0001%.
----------------------------------------------------------
I just detected very very small bug:

Choose CBR setting
Find nominal btrate 411 kbps. After this are: 412, 413, and... 411 again and then 415 normally, 416...

This bug is also in ABR Setting - Min. Bitrate, Nom. Bitrate and MAx. Bitrate.

Good idea. I'll resolve that in the next release.

Thanks for finding that!! It'll be fixed in the next release. Considering how long that 'bug' has been there, clearly a bitrate of 414kbps is in high demand!!

Is that in addition to the currently selected output path, or in place of it? I would guess the former, but maybe you'd confirm that.

Hi John,

Is there any way to add estimated file size for the ogg(s)?

Just for my sick needs nothing important

Not really, because the encoder settings dialogue doesn't know what files are coming yet!! However, the estimated reduction ratio could be added easily enough, if that helps?

If you don't have any better ideas then thats good enough
(any ideas how virtualdub estimates the file size?)

anyway....

what about this:

one input file (.wav) and multiple output files (q1, q2, q3, etc) in one drop.

OK, in the next version.

No idea at all. If you already can determine the size of the input file, then it's easy, but we don't know what's coming at the time of adjusting the encoder settings.

Divided up by cuesheet? I'm not sure I really want to get into that.

Hi John

what I would like to see is the current bitrate at any given time, as in:

total bits in Ogg format encoded so far divided by total timelength encoded so far

So you get a floating bitrate that indicates what one can expect for the song [unless it changes dramatically and you don't know of that.] This could be quite useful for getting to know the character of the Ogg Vorbis encoder

Also, the lossless DLL package hasn't been updated as yet [I'm still getting the older version.]

Finally, would you like me to convert your OggDrop guide and your website to XHTML 1.1 or HTML 4.01 Strict?

Cheers,
CD

Edit: Changed quote date and time to ISO 8601 format.

Confirmed.
In addition to the currently selected output path

[quote=john33,Dec 13 2002 - 01:22 PM]what about this:

one input file (.wav) and multiple output files (q1, q2, q3, etc) in one drop.[/QUOTE]
Divided up by cuesheet? I'm not sure I really want to get into that.[/quote]
no problen there mate I was thinking external file or something pre-programmed menu or setting.
Just brainstorming here. Dont really know enough about programming....

Thnx anyway

You mean in the Nominal Bitrate display as encoding proceeds? OK, will do.

Ooops!! Just uploaded it.

Once the User Guide is finalised, that'd be great, thanks. Regarding the site, that's Roberto's design, etc and he's in the process of redesigning it, I think. Once that's done, you could ask him.

OK, I'll look at adding that in the next version.

Hey, no problem. All ideas and suggestions are welcome.

I mean more like a continuously updated figure of the bitrate for the currently encoding song. For instance, 136 seconds of a 220 second song have been encoded so far, and the current size of the Ogg file [excluding tags and metadata] is 26186528 bits [3273316 bytes], giving an effective bitrate of 192548 bps.

If it's not too processor-intensive, I would love to see the latter value continuously updated, if that's possible


No, I do not intend to change the look, only to clean up the HTML code behind it.

Edit: Changed quote date and time to ISO 8601 format.

From this I assume that you're building the FLAC DLL out of CVS? If so, I'll just insert my obligatory warning that everything new is not fully tested yet and the CUESHEET block format is not finalized.

Josh

P.S. John do the new .dsp projects build everything out of the box fine now?

I appreciate that this is not a properly sanctioned release. However, I am only using the basic file decoding, which I check following a build, and I suspect little is changing there!! In fact, and while you raise the subject, the build I made using the CVS upto and including yesterday produced both a dll and a flac.exe that somehow generated corrupted wave headers on decompression. I did look at the header writing routine and noticed that it had not changed. I did not look further, but wound the clock back 24 hours!

With only a couple of exceptions, for me at least. I've never managed to get any of the test.... projects to compile, but I haven't tried too hard as I don't use them. The only other thing I find myself doing is respecifying the custom builds for the nasm routines.

Yeah, that's what I meant, things will be a little broken for the next couple of days while I get --until (new option) working.

Josh

Hi,

What new features are there going to be in the next release? (other than mentioned here)
Or are we mainly killing bugs now?

Added oggdrop to my new site

Everything committed to in this thread is done and will be released later today.

Outstanding items, IIRC, are dropping directories, as opposed to picking up all the files in one hit, and VorbisGain.

oggdropXPd V1.6 beta 15 uploaded and available at Mirror 1 in all flavours!!

Added features:

• Displayed Nominal Bitrate in Encoder Dialogue also indicates approx. Compression Ratio.
  
• Once encoding begins, the display in the Main Window will indicate 'Average Bitrate xxx.xkbits/s' and is updated as encoding proceeds.
  
• Entering '\' (path separators) into the filename box for Renaming files on tagging will result in new sub-directories being created using the fields to the left of the path separator as the sub-directory name.

Bug fixes will be the only changes now before release of V1.6. Further new features will now be in V1.7.

Oh dear, you're not going to like this one

First the praise: Love the average bitrate display.

But we have a slight åroblem with the creation of directories when using it with tagging/renaming

I encoded a batch of wav-files with their names like this:
Artist - Album - Number - Title

Had chosen a different branching main directory for the encoded oggs ("..\Temp\Encoded\" )

Renaming scheme was "%1 - %2\%3 - %4"

Which I hoped would put my encoded oggs in
..\Temp\Encoded\Artist - Album\Number - Title.ogg" for each album I encoded in the session

What happened was that for each file encoded an additional Subdirectory-upon-subdirectory was created with one encoded ogg in each.

I wound up with a directory-branch like this (for one album)

"..\Temp\Encoded\Afghan Whigs - 1965\Afghan Whigs - 1965\Afghan Whigs - 1965\Afghan Whigs - 1965\..."
...wherein each subdirectory there was a single encoded file.

It was pretty stylish in a weird way, but not exactly useful

@YinYang: Where's the problem? It took hours to get it to do that!!!

Seriously, though, sorry about that, I'll fix it tomorrow.

New beta 15 compiles uploaded and available at Mirror 1 that fix this problem. Compile date is Dec 16.

@John33: absolutely fabulous work there. It's a real treat to see how each song is progressing, what parts eat up how much bits... not just pure eye-candy but an insight into how Ogg Vorbis works. Thanks!

Now for the feedback - brace yourself

1] Selectable temp directory: Would it be possible to set a specified folder as a temp dir for (trans|de)coding purposes? Presently, I am unable to transcode my MAC and FLAC files directly off my CDs as OggDropXPd attempts to decode them onto the CD

OggDropXPd could've been modified to use the destination dir as the temp dir, but then that drive/partition/volume may only have enough space for the Ogg, not the WAV file.

Of course, this would be a workaround until we see on-the-fly transcoding, right?

2] Esc key for dialog exit: I find it convenient to use the Esc key to exit dialogs without saving changes, etc. Would it be possible to incorporate this into every dialog box so I don't have to use the mouse to close it?

3] Editable genre field: One of my favourite Ogg Vorbis features is its tagging system. Type in anything you like without being constrained by pre-defined genres, etc. Currently, OggDropXPd isn't set up to take advantage of this. While I like pre-defined tags [no typing], sometimes an appropriate one is not to be found there.

Monkey's Audio and EAC both have a hybrid genre field wherein there is a drop-down list of the pre-defined ID3 genres, but if you don't find the right one you can type in your own. May I suggest this essential enhancement be made?

4] Show log file + enhancements: It's nice to have a log going on, but I would greatly appreciate a menu entry which opens the logfile. Saves me from having to go to the OggDropXPd directory to view it.

While we're here, a few points about the logfile:

• need average bitrate of each file
  
• need file size of each Ogg
  
• bug - need a space between $SECONDS and "seconds" in the length field
  
• bug - "Channels", "Sampling Rate", "No. of Samples" and "Length" fields' colon character is misaligned [by two spaces to the left]. Also, each field should [IMO] be left-aligned.
  
• bug - time best represented in 24 hr format

5] Enable/disable tagging within Tagging Setup dialog: It's a tad inconvenient to go to the Tagging Setup dialog, only to find the fields greyed out as Auto Tagging isn't enabled. May we get a checkbox in the Tagging Setup dialog to enable/disable it? Please, Sire?

6] Display: This may be considered a bug or a feature, but: after the last track is encoded, the display reads: "Average Bitrate: xxx.x kbit/s". Perhaps this should revert to "Nominal Bitrate: xxx.x kbit/s"?

Phew. That's a fair bit, eh?

Thank you so much for your awesome work here, John. It makes my day when I come home from a weary day at work to see your latest work. I shall drink my next beer to you

Cheers,
CD

Wow! Quite a list! Give me a day or two to absorb this and get back to you.

I wonder if you can add default priority selector to the program? Each time I run OggDropXPd/LameDrop I had to go to the Task Manager and select Low (in Windows 2000/XP). Since I like my system to be as responsive as it is usually, and what I have found that encoding time does not increase at all. Although it is not the case with OggDrop, when I run LameDrop in Normal priority mode it usually happens that LAME terminates with error and in some cases (this is the only time I can see this ) WinXP gives me BSOD. However, if I set LameDrop priority to Low that never happened. (Note I use LameDrop not LameDropXPd, since the latter produces very strange file sizes that are quite different from command line encoder by Mitiok).

BTW, OggDropXPd with Lossless support is a great, great program and huge timesaver, since I don't have to decode stuff. I just can't figure out why dbPowerAmp can't produce good sounding OGG/MP3 files.... , since that is also a great concept program (I don't even need to drag and drop anything) and also dbPowerAmp decodes APE files that never match the original wav... though this is not dbPowerAmp discussion... But the idea, is it possible to add "To OggDropXPd" or similar to the menu of each supported file format? So if I right click on .wav file I just can select "To Ogg..." and everything is started automatically. The same properties for folders would be great as well, so that I can encode ALL files in a folder to Ogg...

Guess too many requests , but program is really good, I already start recommending it to my friends. Finally no-one around uses anything other than CDex (or for some "advanced" friends EAC) and now a couple of friends tried and loved OggDropXPd...

@surge: Thanks for the feedback. I've added you points to the list for consideration!

Right we have to drop the files from one folder at a time to get the tagging done correctly. It would be great that we can select all the folder and drop it to the program and have them all done at once!

CVS should be stable again, can you try the latest John and see if it's OK?

Josh

Heya, John. I know it isn't always nice to ask about release dates, but can you at least give us a rough estimate of when OggDropXPd v1.6 may see a stable release?

Thanks Josh. I'll let you know later today.

If there are no more bug reports, I'll release it tomorrow.

I'm already adding things on the 'wish list', but they'll have to go in 1.7.

Probabbly because your wave files were stored as the older WAVEFORMAT (winamp output this) but this format cannot be used for all the ACM (compression acm codec with windows). dBpowerAMP writes a WAVEFORMATEX header, that is probabbly how the files are different, same sound just different headers.

Already on the 'wish list'. It's needed to do VorbisGain sensibly, too.

@spoon: when I was testing program I believe I used .wav file I created via EAC from CD... I will try more to see if this will happen with wavs from CDex...

From a quick test, all seems fine now thanks Josh.

Hmm, I get an error when I use this string:

Ogg Vorbis\%1\%%1 - %%2\%1 - %2 - %3

with this directory and file naming structure:

D:\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.wav


The error first says that there is no such file or directory, but the path that is says will not work IS displayed on the error as it SHOULD be if it DID work. Without closing the program, if I drag the file to it again, a pattern begins to develop in the error messages after each drop:

1st drop error "D:\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.wav ERROR: cannot open output file D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.ogg is No such file or directory (2)"

2nd drop error "D:\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.wav ERROR: cannot open output file D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.ogg is No such file or directory (2)"

3rd drop error "D:\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.wav ERROR: cannot open output file D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.ogg is No such file or directory (2)"

4th drop error "D:\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.wav ERROR: cannot open output file D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.ogg is No such file or directory (2)"

5th drop error "D:\Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.wav ERROR: cannot open output file D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\Ogg Vorbis\Earshot\2002 - Letting Go\2002 - Letting Go\Earshot - 01 - Headstrong.ogg is No such file or directory (2)"

6th drop error "you get the point"

7th drop error "crashes"

Beta 13 & 14 are the same both are excellent , no problem!

OK, problem resolved, beta 16 uploaded and available in all flavours at Mirror 1.

I'll postpone release of final 1.6 for a couple of days to see if anything else comes out of the woodwork!!

It works!

Well, I was sitting here tediously dragging the new songs to Winamp when I came upon a new idea/request: Playlist creation. This is very simple, take the newly named Ogg Vorbis files and their relative paths and list them line by line in a text file named as one specifies (same %%1 symbol notation) with the *.m3u extention. For example, I usually add a playlist to the root directory, that way when I burn my mp3-cds (hopefully eventually Ogg Vorbis or MPC-CDs ) I simply drag the artist folder and the corresponding playlists to my burning app. Also, when I want to play my music cds off of my computer, I just double click on the playlist.

In this example, my Oggs are outputed to "Ogg Vorbis\%1\%%1 - %%2\%1 - %2 - %3" from "D:\Earshot\2002 - Letting Go\", so the outputted Oggs are placed in a directory called "D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot\2002 - Letting Go\"

I want to add a playlist to the great-grandparent directory "Ogg Vorbis\"
So, I would specify the output directory of the playlist and the name of the playlist as:
"Ogg Vorbis\%1 - %%1 - %%2"

The playlist would be created with relative paths to the Oggs

---------start of playlist text file D:\Earshot\2002 - Letting Go\Ogg Vorbis\Earshot - 2002 - Letting Go.m3u--------------
Earshot\2002 - Letting Go\Earshot - 01 - Headstrong.ogg
Earshot\2002 - Letting Go\Earshot - 02 - Misery.ogg
Earshot\2002 - Letting Go\Earshot - 03 - Get Away.ogg
etc....

--------end of playlist text file----------------


Relative paths are required so one can output the playlist to whatever directory he wants relative to the Oggs and as importantly so that the playlist and Ogg file relationship remains portable and transferable. If one wanted to output the playlist to the same directory as the Oggs, this would allow him to as well. I guess an option to choose between using complete path playlists and relative path playlists would be a nice addition. Complete path playlists allow for only the portability of the playlist without the Oggs, which I find useless to me, but it might be found useful to someone.

Thanks

It is likely that EAC and CDEX both use WAVEFORMAT (EAC does for sure) - one way to be sure is to take your wavefiles from EAC and CDEX and right click >> Convert To >> Wave (same freq)

Then use dBpowerAMP to convert from WAVEFORMAT to WAVEFORMATEX

@mmortal03: The creation, titling and locating of the playlist is simple enough to do. However,...........

@Everyone interested in playlist creation: Does the proposed method meet a general requirement? By using the tag information, it would seem to flexible enough, but I'm not a playlist user myself. Or, are there other schemes in use that this proposal wouldn't match?

Creating the option is simple enough, I'd just like to try to be sure that it meets all requirements. I'm not suggesting that mmortal03's suggestion doesn't work for all, I'd just appreciate some other brains at work on this!!

Good idea, I'd like to hear other ideas as well, as I am not an expert on them, just a user. Maybe Winamp has specifications or standards for them...but I am not certain. Playlists are simply a plain text file, and I would assume that any type of limitations would be found in the reader of the playlist or the limitations of a plain text file, not in the playlist format itself. If there ARE limitations in path lengths etc, I do not know them. Winamp DOES add "useless" #EXTM3U and #EXTINF tags to the path info in playlists when it saves them, according to the title name formatting within the Nullsoft MPEG Audio Decoder settings. "Useless" is my opinion because they are not required for pure functionality. The information contains the Title that Winamp displays and music length information, and allows for the playlist information to be loaded and displayed faster by Winamp without the rescanning of the mp3s for this information (which is done by simply scanning and displaying the file name by default if there are no ID3 tags present and scanning the mp3's length.) I have come to the conclusion that this data is not useful to me, as the playlist functionality is not altered by removing the extra information and it only holds significance SPECIFICALLY to Winamp. (Hardware players skip this information.) There is even a program called id3kill that has an option to scan your playlists and delete this info to save one some Kilobytes. PLS files are another type of playlist used for internet mp3 streams and the creation of these are probably not an applicable or useful function to add to oggdropXP.

So basically, I guess researching these two tags present in Winamp-created playlists might be relevent and beneficial to someone who cares more about the speed of his playlists as compared to the size of his playlists.

BTW, Winamp is set by default to only scan for this information (Title and Length) when the entry for each particular song is viewed on the Playlist Editor panel, and as such only saves the information it has scanned such far when the playlist is saved.
The #EXTM3U tag labels the playlist file on the first line. It is required. The #EXTINF tag is written as follows "#EXTINF:148,Led Zeppelin - Communication Breakdown" Where 148 is how long the song is in seconds. By default when ID3 tags are present, Winamp uses "Artist - Title" and this can be edited within Winamp with other variables. Winamp uses ID3v2 information first, and uses ID3v1 info if ID3v2 info is not availiable.

Playlist creation would be a nice extra.. it would save me from having to shell to the command line and "dir *.ogg /b > albumtitle.m3u"

On the other hand, I personally don't imagine I would use it much with oggdrop, since if I'm ripping a whole CD, I'll be using EAC -- whereas I usually use Oggdrop for single files and odds & ends. That said, it would be easy enough to impliment.

Personally, I would like the option to save the playlist with no paths at all, since I always place my playlists in the same directory as the OGG files -- paths in the playlist will break if you end up copying it somewhere else &/or using it on a CDR.