I don't really care whether it should or not, that isn't my debate
jrlepage wrote:
Delek wrote:
On the real system is impossible, so, every emulator/nsf player that can handle multiple chips are simply not fully accurate.
That's not true. With the right equipment you can play an NSF that uses more than one expansion on a real Famicom.[...]
The Famicom supports it, the NSF format supports it, it2nsf and ppMCK both allow it, so I believe FT should jump on the bandwagon as well.
Quite frankly I'm not all that much into the more technical stuff; I don't understand much of it and I'm not interested in it either. What I am interested in however is writing music. I have chosen the NSF format because I like it. One of the reasons I like it is because of its vast choice of expansions. I like to use more than one of those, and the NSF format allows it. I don't really care whether it should or not, that isn't my debate; but the fact of the matter is that it does. All I'm saying is, if the NSF format supports it, then the "the NES can't do it" argument is moot, because the format we're writing for can do it, and there's no denying that. And if the NSF format can do it, when why shouldn't any piece of software whose purpose is to export to it?
Now if jsr decides that this should not be implemented (and I think I recall him saying otherwise somewhere on this forum), then I'll respect his decision. But I'd still like it to be implemented, which is why I requested it. So there.
You do have a point there; the fact is that most people see NSF files as an actual music format rather than a ROM dump of an NES cartridge containing only machine code for music. Provided that NSF files would strictly be used on home computer systems, it could work out quite well (my major concern was for those who expect it to work on PowerPaks as soon as they load it on).
But you know what would also be nice; aside from exporting WAV files, that FamiTracker could use the LAME (or a similar) MP3 encoder to export to MP3. I feel that this would be a better (& more universal) application for multi-expansion music since you can load the song onto MP3 players & CDs straight off of the tracker (& definitely more universal than the NSF spec).
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
Actually, WAV should be good enough for FT export as far as audio formats are concerned. If you wanted to have a different format, you could take that raw WAV and convert it to MP3, FLAC or w/e else you so desire yourself.
If you wanted to have a different format, you could take that raw WAV and convert it to MP3, FLAC or w/e else you so desire yourself.
At the cost of audio quality. Personally, I like this suggestion of being able to convert to different audio formats other than WAV.
What do you mean about lost audio quality? Maybe if you use less than 320kbps for the mp3 I can understand.
But I actually consider it a non issue. I'm just waiting for the day that NSF really becomes a standard format up there with mp3. (and I saw mentioned somewhere in the forums that and Android phone will play 'em ^_^)
For the time being my process is export to WAV, open WAV in audacity, export to 320kbps mp3.
If you wanted to have a different format, you could take that raw WAV and convert it to MP3, FLAC or w/e else you so desire yourself.
At the cost of audio quality. Personally, I like this suggestion of being able to convert to different audio formats other than WAV.
For the time being my process is export to WAV, open WAV in audacity, export to 320kbps mp3.
Exactly. You won't lose quality because a WAV file is the raw data. It's kinda like recording an AVI uncompressed. It'll be pure data without compression and no loss in quality. Besides, I'm sure you can record the audio straight to FLAC if you want it to be as good as it can sound since FLAC is lossless.
You can call oggenc and LAME from the command-line. Saving you from typing one line seems like bloat.
As for authenticity:
If you don't want Famitracker to be authentic, why use it at all? Isn't that its purpose; to enforce the quirks and restrictions of the real hardware so you don't have to think about it too much?
Why not just use a general purpose tracker with chip samples if you're gonna go nuts and compose for hardware that "Well,...it could, technically, be shoehorned into the NES, under special circumstances, with custom built hacks that are probably too expensive to have existed in the early 90s".
(Even your VRC7 and FME-07 compositions are EXTREMELY unlikely to have ever appeared in a real game Smaller devs might have to beg their boss for a mapper to improve gameplay, let alone for music. A few dollars per chip matters a lot.)
It seems almost as foolish as that made-up chip that BSNES supports. Great, it's technically compatible with the hardware, but where are you gonna get 4GB of storage for like $30 in 1995?
I just don't buy the "I just like the sound" argument. I think it's disingenuous. When people make NSF files, they feel like they're making "real" NES music, as opposed to those lowly scrubs who sequence in bulky, multi-purpose DAW.
....and that's fine, but KEEP it authentic, then!
It would hardly be the worst thing in the world, it just seems to defeat the purpose. Might as well make it a do-everything tracker that happens to spit out NSFs sometimes.
Imo we should stop this whining about the whole multi-chip thing and just let jsr decide on his own. I'm sure he won't really appreciate having to wade through 4 pages of uneventful banter.
Might as well make it a do-everything tracker that happens to spit out NSFs sometimes.
that's actually the premise of it2nsf.
yup, it seems folly to add anything to famitracker that isn't supported by nsf format. it's a NES tracker by name. the thorny issue is that nsf does support all expansions used simultaneously, though it's basically an emulator fantasy. it just doesn't seem important anyway... it's a novelty, and in practice not really any different to IT/XM, just has fancy names and coolfactor.
Imo we should stop this whining about the whole multi-chip thing and just let jsr decide on his own. I'm sure he won't really appreciate having to wade through 4 pages of uneventful banter.
Alright; I thought we were past the issue of multi-expansion NSFs. I'm with Raijin on this; even if it's a novelty & in spite of our own little arguments, it's ultimately nothing more than a suggestion that JSR can accept or reject for his future releases of the program.
psn wrote:
Raijin wrote:
If you wanted to have a different format, you could take that raw WAV and convert it to MP3, FLAC or w/e else you so desire yourself.
At the cost of audio quality. Personally, I like this suggestion of being able to convert to different audio formats other than WAV.
Raijin; the premise of my suggestion was so that the raw output of FamiTracker could be directly converted into a more standard file that can be more portable than WAV files (considering that a standard 128 Kb/s MP3 is about a quarter the size of a WAV file of the same recording time). Sure, we can go the route of creating the WAV file, opening it in Audacity or Vegas Pro & convert it to MP3, but why do so many steps when it can all be consolidated into one single function from the tracker itself?
psn; regardless of how audio is exported, it's not the steps that determine how much loss there may be during an encoding process; it's the encoder itself that determines that (i.e.: whether or not I convert a WAV to an MP3 or directly export the audio output to MP3, I'll still experience loss because I'd always be using a compression algorithm to encode the MP3). Furthermore, I've actually converted WAV files of my tracks to 64 Kb/s MP3s & have still maintained a decent quality (the only noticeable difference is a slightly decreased master volume in the MP3 file, which can easily be adjusted in an audio editor without compromising on quality or file size).
Now, I've suggested the MP3 export in particular for a couple of reasons:
1. Portability (because you can add MP3s to CDs without conversion, you can play MP3s from any portable music player & you can even store them on flash media to play from DVD players).
2. Multiple uses (you can still maintain good-quality MP3s at 64 Kb/s with just about any chiptune, so MP3 would be ideal for streaming on websites or even including in any game design project, be it Flash, Java or any other programming language).
3. Compression (yes; even though I prefer FLAC, it still hasn't caught on as much as it should have in the industry & MP3 files can still achieve better compression ratios, thus the reason that it can be used for many applications).
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
(and I saw mentioned somewhere in the forums that and Android phone will play 'em ^_^)
iPhones already do! There's a third-party app in the App Store called Noise Entertainment System (or NoiseES) that plays NSF, NSFe and GBS files. No support for VRC7, MMC5 or FDS sound yet though, but it does play multi-expansion tracks, and fairly accurately too from what I could tell.
I don't think Shaun Inman (the man behind NoiseES) has ported nor plans to port his application to Android phones though.
The Android application I mentioned was Droidsound. It can play many different module files. Not only can it play things like VGM, NSF, GBS, etc, but also things like XM, IT, S3M, MOD, etc. It's a pretty powerful application.
The only expansion it doesn't support is VRC7, I think.
Getting back to the FDS, I have noticed that instead of a stepped waveform like I have been used to and love (thank you for that) you have linearly smoothed out the waveform, which is cool and all, but could there be a way to actually toggle between the linearly smoothed out result and the stepped version? I do like both, and that would be very handy to have.
On the other hand, I wonder if both could be combined simultaneously... That could be cool and very useful as well. That way you could have the different level steps AND be able to see how it would look as an actual linearly smoothed out waveform - at the same time.
Would either the toggle option or the superimposed option work, and which would be easier for you to implement?
_______________________
You now process Dracula's Rib. Good luck processing it...