A program...

[SSJ4 Gogitta]

... If someone can make it.


I'd like a program that will convert/export a single or multiple winamp m3u (playlist) files into a single NERO NRI (regular data) or a NERO NRA (audio CD) complation file.

Currently using Winamp 3.81 and NERO 5.5.8.0

attachment of my playlist and a small nero NRI file to help anyone who can make this program.

The program would save bunches of time. instead of going through hundreds of directories and drag/dropping lots of files, simply export the playlist into a nri file and burn away.



Many many thanks to someone who can make this.

[Some1]

I'd do it (it's certainly a more interesting project than that essay for COM class that I should be writing), but the formatting of the .nri file is beyond my grasp (unlike Winamp's .m3u, which is beautiful in its simplicity)...maybe if you could post a sample of a .nra file, as it's possible that it uses a simpler format (though not likely...).

[SSJ4 Gogitta]

Originally posted by Some1
I'd do it (it's certainly a more interesting project than that essay for COM class that I should be writing), but the formatting of the .nri file is beyond my grasp (unlike Winamp's .m3u, which is beautiful in its simplicity)...maybe if you could post a sample of a .nra file, as it's possible that it uses a simpler format (though not likely...).

::points at attachment...::

[SSJ4 Gogitta]

urg...


NRA file..

[Some1]

The .nra file IS quite a bit simpler than the .nri, now there's actually a chance that I could pull off such a program...I'll give it a shot, though I can't say right now whether or not I can actually pull it off.

[Jay]

are these files an open standard or a Nero only file, they look like nero only files, and therefore could be full of data that we just don't know much about, anything done here would be strictly a hack unless you can get the nero people to share their format with us.

[Some1]

are these files an open standard or a Nero only file, they look like nero only files, and therefore could be full of data that we just don't know much about, anything done here would be strictly a hack unless you can get the nero people to share their format with us.

From what I can tell, the format looks proprietary but not all that complex (I'm looking at the data in a hex editor). The .nri file IS definately full of data whose purpose is a mystery to me, but the .nra file looks pretty straightforward...frankly I don't care about whether or not making an app to convert between filetypes counts as a "hack" or not...I have every right in the world to program something that transcodes filetypes if I so desire.

[Some1]

Progress Report: My program is currently at a phase where it can take the track title information and path from the .m3u file and place them into the .nra file in the proper format...so the easy part is done. The hard part now is to duplicate the formatting that the .nra file has between this information. If you could post a .nra file composed of MP3's whose ID3 tags are NOT filled in, or whose ID3 tags contain ONLY title and artist, it would help me greatly (though don't do a mix of not filled in and title/artist only). The problem is that the .nra stores all the ID3 info on the file inside itself, and it uses various flags to delineate the different data fields...this data is NOT necessary for successfully burning a CD however, thus I just need to figure out how the file is formatted when the files have no ID3 tags, or at least when they have very simple tags.

There is one irreconcilable issue between the two formats to report as well...the .m3u file does not (or at least doesn't seem to) contain pathing info w/ respect to what actual drive letter the files reside upon, but the .nra requires that all file paths be preceded by the appropriate drive letter. The way I've handled this problem is to have the program prompt for a drive letter before it starts the conversion, but this means that if all the MP3's in the list aren't on the same drive then the conversion won't be perfect. The other possible solution (short of having my program actually search for the proper path itself...) is to prompt EVERY time a new entry is processed. This would allow the program to handle files across multiple drives, but would also make it annoying to use...so far I'm sticking with the first option.

Edit: Another interesting thing...character 13 (which is used to delineate entries in the .m3u file) doesn't seem to like the ifstream.get() function...I'm sure there's some reason for this that professional programmers are all well aware of, but trying to track don't that unusable character was driving me insane. Luckily I can just as easily use character 10 to delineate entries since it always follows character 13 in the .m3u file anyways (and character 10 isn't a bitch when it comes to ifstream.get()...lousy character 13...thinks it's so big and special...).

[SSJ4 Gogitta]

Here are 2 NRA's.

one with ID2 tags, one with NO tags...

This will be the last post i can make till about 3 pm. gotta get to bed.

Thanks for working on this... will be very usefull!

[SSJ4 Gogitta]

k, i lied


one last discovery...


All the MP3s on my playlist are in my C: drive... So i added one from my D drive and saved. here's what i got:


#EXTM3U
#EXTINF:265,3 Doors Down - Be Like That
\WINDOWS\Start Menu\Music\_A to F\3 Doors Down - Be Like That.mp3
#EXTINF:233,3 Doors Down - Krytptonite
\WINDOWS\Start Menu\Music\_A to F\3 Doors Down - Krytptonite.mp3
#EXTINF:245,Avril Lavigne - Complicated
\WINDOWS\Start Menu\Music\_A to F\Avril Lavigne - Complicated.mp3
#EXTINF:220,E.S. Posthumus - Pompeii
D:\E.S. Posthumus\E.S. Posthumus - Pompeii.mp3


The one on the other drive DOES show the drive letter.

[Some1]

Those files should help a lot, although the fact that the .m3u file DOES keep track of drives will require a little redesigning on my part. I'm done programming for tonight..given the rate at which things are going I'd predict that I'll have the app ready either late tomorrow night or sometime the day after.

[binary hero]

you know some1, you seem like one of those Useful people, who should always be hanging around.

translation: stay around here or you will be hunted down and hurt. really hurt.

[Jay]

Originally posted by Some1


From what I can tell, the format looks proprietary but not all that complex (I'm looking at the data in a hex editor). The .nri file IS definately full of data whose purpose is a mystery to me, but the .nra file looks pretty straightforward...frankly I don't care about whether or not making an app to convert between filetypes counts as a "hack" or not...I have every right in the world to program something that transcodes filetypes if I so desire.

No one said there was anything wrong with hacking your way through it, lets not be so touchy.

[Curi0us_George]

Originally posted by Some1
Those files should help a lot, although the fact that the .m3u file DOES keep track of drives will require a little redesigning on my part. I'm done programming for tonight..given the rate at which things are going I'd predict that I'll have the app ready either late tomorrow night or sometime the day after.

Yeah. By default, any files listed in an M3U have a "local" path. Winamp seems to put only enough information in so that they can run. I assume that is so that if you drop the m3u in the directory with the MP3s (or in a directory which contains the MP3s in a subdirectory), you can move the entire directory, m3u and all, with no problems.

[Some1]

No one said there was anything wrong with hacking your way through it, lets not be so touchy.

Sorry, it's just that most of the time when I come across somebody using the words "strictly a hack," they're doing so in a negative/disapproving manner.

Looking at some of the .m3u files on my computer, they seem to store pathing info relative to the location of the .m3u itself (probably for the reason Curi0us_George indicates), so all I need to do is make my app remember where the .m3u it's opening is, and everything should work.

[Some1]

Another Update: I've now fully "cracked" the .nra format, which means that I should be able to make the files generated by the app fully compatible with Nero, although a little reworking is in order, as some data which I thought was mostly useless is actually being used to store the length of the next entry in the .nra file. I still expect to have a prototype version working by either sometime late tonight or tomorrow.

[RanDom_ErrOr]

YOU ARE A GOD IF YOU CAN PULL IT OFF!!!

ive been looking everywhere for a program like this... THANKYOU for your time and effort... (i can beta test if you need it)

good luck and keep us posted (ah ha a pun)

[Some1]

The app is coming along nicely, and is almost to the point where I'd feel comfortable posting it on the Net...there's just 1 byte that's giving me problems...once I derive a way to calculate its value everything should fall into place.

[simon snowflake]

This sounds über kewl.

[Some1]

Well, I just fixed the last problem I was having with that byte, and ran my app on SSJ4's test playlist and opened the file with Nero, and all things seemed okay...Nero opened the file without complaining about it being invalid/corrupted, and then promptly informed me that it could not find the songs listed in the .nra file (which makes sense since it's SSJ4's playlist and not one of my own)...now comes the moment of truth, I have to test it with one of my playlists and see what happens.

EDIT: The results are in, and I'm DAMN close...the first 5 elements from my playlist loaded into Nero perfectly, but all the songs after that it didn't even see. I'm guessing that this is because both the files I was using as examples contained only 5 songs, and the byte(s) which store the number of elements got overlooked because they were identical in each of the files...fixing this should be fairly straightforward, though don't quote me on that.

EDIT2: Found what appears to be the byte, fixing the code now...apparently, info about file size is held in in several different nonconsecutive bytes in the header of the file...this will take slightly more time to fix...

[simon snowflake]

/me is crossing his fingers

[Some1]

ahahahahahahahahaha I made it work!!! And after spending the better part of an hour looking for discrepencies in bytecode when it was actually a logic error that was giving me problems...things like that just make me feel stupid. Anyways, the program seems to be 100% functional, so I'm going to do a couple more tests to make sure, write some quick instructions, and then post a link for people to d/l and play around with it (assuming the additional tests go well).

[SSJ4 Gogitta]

Oooh.. fucking awesome!

now for the NRI part, for nice MP3 cds!

[Some1]

Well the program passed 2 of 3 additional tests (the third it failed due to a known issue with complex ID3 tags), giving it a decent success rate of 3 out of 4, so I guess I'll put it up so that people can take a look at it. Keep in mind that this is VERY early version software, and when I was coding it I wasn't trying to make it particularly elegant or user-friendly (I just wanted something that WORKED)...if people actually start using it then maybe I will. Just make sure you read the documentation before using it...enjoy:

[SSJ4 Gogitta]

nice, but sadly, dosent work on my end yet.

Tried several different ways, and nero tells me "Failed to open document"

oh well, it isnt called an alpha for nothing, lol!

Keep up the good work though!

[Curi0us_George]

If you post the code and I have some extra time, I'd be glad to take a look at it and see if I can help.

Of course, if you don't want to post the code, that's undertsandable, too.

[Some1]

nice, but sadly, dosent work on my end yet.

Tried several different ways, and nero tells me "Failed to open document"

oh well, it isnt called an alpha for nothing, lol!

Keep up the good work though!

This is probably because of the ID3 tag issue...if you could post the playlist you used, the file that my app generated, and a real .nra file made with Nero that contains the files in your playlist it would help me out. I've got a couple ideas on how to fix this, though neither one is trivial (one involves prompting about the presence/lack of ID3 tags and then trying to derive the tags from the filename, which is fairly easy to code but not likely to be reliable, and the other involves opening each MP3 file and parsing the ID3 into directly into the output file, which should work almost all the time but would be a bitch to code)...in the mean time, try removing or editing the ID3 tags from the files in your list and see if that does anything...

If you post the code and I have some extra time, I'd be glad to take a look at it and see if I can help.

Of course, if you don't want to post the code, that's undertsandable, too.

I wouldn't mind posting it, except the code is really UGLY right now because it's been revised so many times...maybe I'll post it after I clean it up some.

[Curi0us_George]

Cool.

ID3v1 tags are beautifully simple. ID3v2 is completely the opposite. They made them about as complicated as possible, and then added to it just to mix it up some more. I really hate the way they did ID3v2. Several times I've started work on ID3v2 parsers, but I always give up because it's just not worth my time. They're so ridiculously complicated, considering what they do.

[Some1]

Apparently you're not the only one who doesn't like ID3v2 tags...Nero will ignore these tags as well when it generates a .nra file, so all I have to worry about is parsing the ID3v1 tags.

EDIT: I just confirmed that if a file has ID3v2 tags with no ID3v1 info my app will work, likewise if the file has no tags whatsoever, so all I need to focus on is taking care of the ID3v1 part.

[Some1]

After some extensive testing it seems that the ID3 issue is not the cause of the non-working output files...I'm still looking for what's really causing it...having certain files in the list seems to be what sets it off. So far every file I've found that makes it fail has a VERY long filename...I'll just have to play around with it some more and see what happens.

[RanDom_ErrOr]

w00t w00t it worked here!!!

heres sample files...


only prob i have, is that it doesnt suck the Title and Atrist from ID3v1... maybe you should do that (please)...

[Some1]

Well it's nice to know that the program is working for somebody other than myself. Long filenames ( > 48 characters long as a conservative estimate) ARE what's causing the current unreliability, so next on my list is getting this issue fixed. I have the code for extracting ID3 tags mostly completed, so once I finish with long filename support I'll probably finish implementing it and then post the fixed version. From the test that I've been running, the current version on my computer can handle all the following situations reliably:

Any number of songs with short names which do not contain any ID3 info, located across any number of different folders/drives, using any naming convention(s).

Any number of songs with short names which contain ID3v1 and/or ID3v2 info, located across any number of different folders/drives, using any naming convention. Info in ID3 tag does not have to match naming convention(s).

Any number of songs with short names which do not contain any ID3 info, mixed with any number of songs which do have ID3v1/ID3v2 tags in any order, across any number of different folders/drives, using any naming convention(s).

A list containing a single long filename may work provided that the long filename is the last entry. Nero will not be able to read it, however, and will give you an error message wbout how it cannot find the file, thus making it pointless to have the long filename in the playlist in the first place.


Support for any length filename and ID3v1 tags is pending...also, if you are using Winamp 2.xx to generate the .m3u file, make sure you have the playlist configured so that it displays songs in <artist> - <title> format. This may prevent some issues with the version posted above, and will help to ensure that the filepath is always the largest element of data in each set (which is important because I plan on using the path to determine whether an entry counts as a long entry or not...although I guess I could just as easily check both fields).

EDIT: The long name problem is pretty simple actually...if the length of an entire entry (path + filename + filename + ID3 tags + "blank" space used to seperate + bytes used to indicate the length if each individual part) is greater that 255, extra characters are needed to represent the length...I predict that fixing this will take about 5 mins. I guess I'll start rambling about this stuff and go code now.

EDIT2: it worked...the app now supports all files up to a length of 255 * 255 characters long. They don't even MAKE an operating system that would let you overrun that buffer...

[Some1]

Id3 support is giving me some trouble, as I've yet to figure out a fast and reliable way to traverse the MP3 file to where the ID3 tag is (although once I get this all the other code is in place), so I'm going to post the new version anyways so that anybody who couldn't get the first version to work can try this one. It's much more reliable and can handle a greater varietry of situations than the predecessor, so if you had problems with the previous version give this one a try:

[Curi0us_George]

What kind of ID3 tag reader are you needing. I've got an ID3v1 tag reader in Java. It shouldn't be much trouble to convert it to C++. If you're wanting ID3v2, that'd take a bit more time.

The ID3v1 tag will be located at "size - 128", if it exists at all. The first three bytes should be {84,64,71} (TAG).

[SSJ4 Gogitta]

success.

Alpha 2 worked on my end for a small playlist. the mp3's had no ID tags though.

Just tried it with both ID3v1 and v2 in the mp3's. Worked.

[RanDom_ErrOr]

cant test it at school, but i have alot of long filenamed songs... will try later...

[Some1]

What kind of ID3 tag reader are you needing. I've got an ID3v1 tag reader in Java. It shouldn't be much trouble to convert it to C++. If you're wanting ID3v2, that'd take a bit more time.

The ID3v1 tag will be located at "size - 128", if it exists at all. The first three bytes should be {84,64,71} (TAG).

For now I just need an Id3v1 reader. I might add Id3v2 support later just for fun, but Nero doesn't have any native support for these tags, so they're not a priority. Like I said, I have most of the code already, all I need is something that will return the size of the MP3 file so that I can seekg() to the right place...all the methods I'm used to using fail because they see "END OF FILE" tags at fairly random locations in the file.

[whiteflip]

I forgot but does a PLS file save the entire path? If you take your m3u's and save them to a different drive it will do the full path for C:\. Winamp should have an option to save playlists with full paths.

I've used drag Nero. You can just drag m3u's into an audio playlist thinggy.

[Curi0us_George]

Some1:

code:


ifstream is;

is.open ("test.txt", ios::binary );



// get length of file:

is.seekg (0, ios::end);

length = is.tellg();

Thanks to cplusplus.com

whiteflip, the point of not encoding the full path is so that the playlist, and the MP3 files can be moved, together. Otherwise, you'd have to recreate all of your playlists if you moved your MP3s. Using relative paths also save space.

The option would be nice, though.

[Some1]

Thanks to that handy (and elegantly simple) code snippet, ID3v1 support should be completed shortly, not to mention some basic error control as well as no more need for the third parameter (the base directory).